Spatial definition query

04-26-2010 04:36 AM
Status: Under Consideration
Labels (1)
Occasional Contributor

I would like to be able to apply a spatial definition query to a layer.

I.e. Select features from this pointlayer that are within a feature from buildingpolygons.

Defining a query must be as easy as it can be done in the Select By Location dialog.

The result of the query is updated when features that are involved are modified.

I would really love to be able to use this functionality in SearchCursors to minimize the number of features I need to loop through.
You can't publish services with the "Clip to Shape" function turned on.  The work around doesn't even work for everything.  AutoCAD has had this for a few years now, maybe more.
I would love to be able to use this for editing, for example finding all points that aren't connected to lines, and having the selection refresh after edits.

This idea is a good start to a similar idea I had.

Instead of simplifying it to Clipping it would be awesome to allow definition queries that implement the arcpy Geometry api, or the SQL relational functions for ArcSDE.

Arcpy Geometry API:

Geometry—Help | ArcGIS for Desktop

Select features that are with 10 units to another:

where: SHAPE.distanceTo(other_table.SHAPE) = 10

Select features contained in the other:

where: SHAPE.contains(other_table.SHAPE)

SQL Relational Functions:

A quick tour of SQL functions used with ST_Geometry—Help | ArcGIS for Desktop

For example, select features that touch another:

Where: SHAPE@.ST_Touches(other_table.SHAPE@)

features that are equal to another (geometrically):

Where: SHAPE@.ST_Equals(other_Table.SHAPE@)


While I agree that such functionality would be handy, it does come with some risk.  Spatial predicates are much more expensive than other predicates in DBMSs, and that is true when spatial indexes exist and are well tuned.  If data sets either don't have spatial indexes, don't have them well tuned, or the DBMS chooses not to use them; well, the performance can be downright miserable.

Given there is a very real chance the performance of a spatial predicate will be quite poor, the software maker takes a beating for something they have little control over.  What if a spatial predicate takes 2+ seconds to execute, possibly even 5+ seconds?  Every time a user goes to zoom or pan, the screen just hangs for protracted periods of time.  What if a map service is made out of that layer, how will that look to people consuming the service?

I can understand the desire for such functionality, I just think there is too much risk involved for Esri.  Over time, the risk may diminish and make it more feasible, but I don't see it happening in the near term.  That said, if one is working with enterprise DBMSs, then some of this functionality can be implemented at the storage level and brought into ArcGIS.


Also, clipping clips labels. Can look awkward.


While this can be achieved by using a normal definition query and utilize the used RDBMS spatial capabilities, it will however require disabling the standardized queries on the ArcGIS server to be able to spatially filter against a map service.

Providing such function by ArcGIS would be much cleaner. 


This workaround does not limit the data in the database. It only limits what is drawn in the clipping extent.


I understand performance is a problem, but would it be possible to cache the selection set? E.g., You open the map and the layer with the spatial query grabs an up-to-date snapshot and caches it (or a portion of it, like Feature Cache in ArcMap) and remains static for the rest of the session or until the user chooses to manually refresh. This wouldn't work for constantly changing data, but it seems like it would work fine if the data only needs to be refreshed daily or weekly, and it's being used as a reference more than for active editing. Maybe that's too big of a caveat to bother explaining or implementing, but I think it would be worthwhile.


I see what you are getting at, and it isn't a bad idea, but it comes with risks as well.  Caching addresses some aspects but introduces new issues that either need to be mitigated or documented and communicated to users.  As good as documentation may be, we know most users take a cursory look if they bother to look at all.  When new functionality performing well depends on numerous fine-print details that few will read or understand, users start complaining "it doesn't work" whether it is warranted or not.