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.
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.
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.
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.
It's obvious after using Map Series for 2 days that this is a glaring omission.
This idea was posted in 2012! WOW the wheels grind slowly in EsriLand!! Anyone suggesting that Definition Queries and scale ranges probably needs to try actually working with ArcPro
All ESRI (or anyone else - there is money to be made, doesn't seem ESRI will never make OTB mapbook better) needs to do is duplicate this program's functionality in Pro:
http://maplogic.com/products/maplogiclayoutmanager.html
It's freeware now and per the developer won't ever be made into a Pro version.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.