DDP query various data with a custom wizard.

[PeterGoodman1]

Our office is developing a fairly large parcel index and the people who will be using this information are mostly:
1: Not regular Arc View users.
2: Need information quickly.
3: Be able to pull different information without having to go through long winded or difficult queries.

What we have developed so far:

Data driven pages that show individual lots with all necessary data shown. (owner, address, legal disc., Lat Long, etc.). Ancillary data such as legends, North arrows etc. are added in.

The maps will display each and every single lot separately in a pre-formatted .mxd that is printable. The background data is Read-only to prevent overwrites or inadvertent edits.

Each parcel is easily viewed by simply inputting the key value in the "Page Name" attribute of the DDP command bar which is directly linked to the key attribute in the data table.

The problem comes in that many of the parcels we index have missing key data (most �??fake numbers�?� are typically 0). So to find various parcels, the assessors, field techs and most everyone else who is NOT a mapper, uses various means to find that data. Including the above listed attributes and inputting owner names, Situs addresses, etc.
But, the DDP system only allows for a singular query from only the DDP command bar.
So, is there a way to set up a query wizard, or some other means of say a window or radio button of some kind where the address data, account number, owner, Lat/Long or any other data could be entered for a query and the DDP can then query that data and display the lot as normal?


Thank you in advance.

[MarcoBoeringa]

From what I have seen up to now, if you want to stay within the realm of the DDP functionality and be able to use the standard tools and toolbar to accomplish what you want, there is no real other option than creating *multiple* parcels polygons for the same lot each having a single attribute of the type and content you want (parcel number, owner etc.).

This is not an ideal situation, because it will mean having overlapping polygons, but you might automate the maintenance of the DDP polygon index layer by using ModelBuilder tools to stack polygons based on the same lot and add the attributes from whatever source you are using, and than schedule to update the layer each week or day or so...

Problem is, it seems ESRI hasn't yet exposed much of the DDP functionality through python, except the most basic functions. Hence some stuff, like the "Page Definition" on a layer, isn't available programmetically.

Seems we need to wait for ESRI to upgrade DDP functionality and expose more through programming interfaces like python.

[JeffBarrette]

I agree that DDP is limited in terms of query capabilities (and other capabilities as well).  It was designed with a simple interface but it can be further extended via arcpy.mapping.  I have to disagree with the below statement that arcpy isn't far enough along.  For example, a page definition in arcpy.mapping is simply a layer's definition query.   See recent post on this topic:

http://forums.arcgis.com/threads/67271

Some thoughts concerning this application idea.
1) One of the basic rules in setting up DDP is that each DDP index feature have a unique value.  In this case, the values are not unique so how does DDP know what feature to go to?
2) If the values are not unique then I don't think I would use that field.  I would probably use something like OID instead and then generate my own parcel parcer via arcpy.mapping.  For example,  I would build a script tool that displayed multiple field inputs (the first being required, and all the other being optional).  In this example, the first field would be parcel id.  If the value is 0, then I would use a second field to further isolate my selection (perhaps owner name), etc.  Using the scripting logic a query would be built against the database.  Based on the query, internally, I would return the proper OID and automagically set the DDP to match that OID.
2) All of #2 but do it in a Python addin rather than a script tool.

To summarize, this becomes a very custom application which would never be a one-size-fits-all type of query in the out-of-the-box DDP.  This is partially why arcpy.mapping was made avaiable (I say partially because it can do a whole lot of other stuff too).

Jeff

PS - ok, ok, I know some of you are going to flame me for this response.  🙂