Page Definition Query improvement

1497
6
11-21-2012 07:10 PM
Status: Open
Labels (1)
AdamForknall
Occasional Contributor III

Page Definition Queries are very useful, however they have the potential to be much more so. Rather than only being able to turn features on/off based on them having a field which matches (or doesn't) the page name, the ability to use SQL queries (mush like regular definition queries) would enable much greater scope for filtering features.

An example might be a a state-wide feature class containing many classes of road from major highway to dirt track. Depending on the scale of each data driven page, the level of road class dsplayed may need to be changed (i.e. only showing major highways at small scales when lower classes cause cluttering, and showing minor roads/tracks at large scales).

To facilitate this, the Index Layer would be populated with fields corresponding to layers which are to have Page Definitions applied. These fields would contain the values to be matched in the definition, in the above example the values would be road classes. The Page Definition could then contain an SQL query where the field in the road dataset containing Road Class is selected, a boolean operator is selected and the corresponding field in the Index Layer is is selected.

The below example selects the major roads (Classes 1 & 2) for display on the State-wide page.

0EME0000000TU6b

6 Comments
ChrisFox
Currently the most efficient way to accomplish this in both workflow and drawing performance is to author the symbology for multiple layers that makes sense at each scale and then set visible scale ranges on the layers.
AdamForknall
That's great that there is a way to achieve this Chris, and while it is the most efficient at the moment, I believe it's not the BEST solution that could be provided.
ScottMoucka1
"Page Definition Queries are very useful, however they have the potential to be much more so."

Could not agree more! I'd promote this 10,000 times if it'd give this idea the attention it deserves.

I'm currently supporting the creation of a statewide atlas. The tiles are based on townships and these often reside in multiple counties. In the locator map we are highlighting the counties in which the tile sits.

As far as I can tell the current functionality of DDP and Page Definitions does not allow for multiple counties to be selected (Please correct me if I'm wrong!). Not to mention I'd need to switch the page name in DDP to a different attribute and that attribute would need to contain values for several counties. The ability to use SQL queries would be incredibly valuable! This seems like a no-brainer to me.
KeithAddison1

I'd love to see this also.  There is a partial workaround I find myself doing: add extra fields to all the relevant data that match the page name map series fields and use those fields to attempt to control visibility.  This isn't always possible though depending on the complexity of how and what visibility and symbology I'm attempting to control, it only works for simple situations.  I'm using Pro and if Pro has a solution I haven't found it yet.

Michele_Hosking

I've just discovered these page queries (I try not to make maps! :)) and I am finding it limiting to have to match the name of a map to a field in the data.  I am creating a map series where most of the individual polygons I am using fit on a map at a reasonable scale - but one does not. I would like to show this area on two maps but this is one polygon, with one name (Rangitaiki). I would like two maps (Rangtaiki part 1, Rangitaiki part 2).  I don't want to split my polygon - I don't want this to look like two separate areas on the map - 'cos it's not. And this is real data so I can't go changing it just to create some maps. I can't have two maps called the same thing - as these will (I assume) just link to the same map extent.

Can we please have actual sql queries for this so it works just like definition queries?  Or can we link to separate layers so we could put a layer in multiple times with definition queries to separate out what we would like to see on each map and then have the map series link to each layer based on the map name?

Or - just thinking - could the sql query be part of the mapsheet/index feature class as a field?  You know the feature class used to create the map series where you store the map name, scale for each map etc.  If we had a field that could hold a sql query somehow (not sure how) and then the map series could read this to change the data.....

Anyway it would be great if this feature was more flexible.

 

KeithAddison1

Mapbooks in Pro need to be able to take an full SQL statement for the 'Page Query' instead of just locking you into a simple statement limited to just one attribute. 

Right now if one has multiple layers that you need to query on and off using multiple attribute fields there are three workarounds, each with significant pitfalls.  Workaround 1: Make a whole bunch of separate layout & map tabs, major pain is this slows the aprx down and requires a collation process after outputting multiple map series.  Confusing for someone who didn't create the mapbook to figure out.  Workaround 2: Turn the layers and queries you need off and on as you go about exporting individual pages, also confusing for someone who didn't create the mapbook.  Wokraround 3: Python script something to do this, not good for people & organizations that don't have time to learn Python for no other reason than fix the holes in the software their company paid lots of money for.