Dynamic Spatial Definition Queries

[DavidFotheringham1]

The inclusion of spatial based definition queries to 3.5 is great. My immediate thought was to check if they were dynamic, i.e. if my polygon extent changes does my definition query update accordingly. The answer is no. It sticks with the original geometry unless you go back in and reapply the query.

I think there should be an option to allow this to be dynamic (it would be for attributes). I might be using a polygon I don't control / have ownership of and don't know if it has changed. My queried data would be out of data in that case.  (see my picture example below. Blue points are in the definition query. I updated the polygon extent but the blue points are not changed).

Red points not captured when polygon extended. Blue points are part of definition query

[JoshuaBixby]

Although I understand the value of having this functionality dynamic, and I don't think implementing a naive approach to it would be difficult, the fact that spatial operations are so compute intensive makes implementing an efficient means of doing it very challenging.  For the example given here, even a naive approach would likely perform fine, but what happens when there are millions of points or the polygon itself has tens of thousands of vertices?  In that case simply panning or zooming a basic map would result in the noticeable, if not significant, delay in refreshing the screen.

Raising ideas is good, and I think the discussion around them in the community is good for Esri to read, but this is one where I would not hold my breath. 

[MichaelVolz]

How often does the data change where the spatial definition query becomes obsolete?

Can you programmatically update the spatial definition queries nightly, weekly, etc. using a python based scheduled task?

[TanuHoque]

Thanks @DavidFotheringham1 for submitting this idea. We have heard this request before.

Do you happen to have any real world workflow from your side which be benefitted by this?

[RTPL_AU]

@TanuHoque 
Does this Idea intersect (pun intended) the map clipping layer code-base?

I assume that there are a few similar mechanical bits in the background as both Clipping Geometry in the Map Properties and Spatial Def Queries use the clip/filter/boundary geometry only at time-of-query.

I often want the Clipping Layer to be dynamic so as project boundaries change over time, I don't have to manually check & fix each map/layout when updating something else. 

A real world workflow for this Idea - We support clients who have people running around the bush collecting fauna & flora data with regards to environmental offset areas, pre-construction impact assessments, etc. 
There will be a lot of static layouts (Maps) created of the planning process and results for reporting purposes. During project execution the study areas may change.
If we use spatial def queries to clip data from a larger set into those visible in the study area only, we have to go through all the steps for each layer in each Map to apply updates when they arise. 
It is a goal to use the same dataset for as many purposes as possible, and not to create derivatives for every scenario - but in this case it is much more efficient to create a new derivative clipped dataset for every boundary change compared to updating the query for every layer impacted by a boundary change. 
I am sure some of it can be scripted but I will still be opening every Map to make other changes (doc control numbers etc, updating symbology/legends/etc) as required. 
Having the Spatial Def Queries (and Clipping Areas) update automatically would be a massive time saver.

I understand the caveats around continuously updating/running spatial queries  - adding this burden to the already sluggish interface is not a good outcome for anyone so maybe a button can be added somewhere to have these queries updated by user request?

[RTPL_AU]

@TanuHoque 
/2

Imagine having a 100 figures to update in a Significant Impact Assessment. Each Map may have several layers (say 5) affected by a study area change.

This means we have to run the query process 500 times to have it update the results.

We still need to open the Maps to update other things but not having to go through the manual query update process with all the associated mouse movements and clicks would be fantastic!

[DavidFotheringham1]

@TanuHoque the workflows I have in mind are similar to @RTPL_AU. A whole bunch of figures which need updating because a project boundary has now changed. We already have python scripts that work through folders and aprx and export all the figures. It would be amazing if any spatial definition queries are also updated based on current boundaries. No need to open the APRX at all.

Another workflow would be for intersect counting. The project boundary may stay the same but the national designations might have been updated (e.g. historic listed buildings) and we could set up dynamic spatial definition queries to easily get an output of how many and which ones are in the project boundary. I know we could just so select by attribute etc but the ability to do this via dynamic definition queries adds another option, especially to those in the team that aren't as experienced in Python scripting.

I understand the points that a dynamic set up might be more intensive and as such might be best served with an option to turn ON dynamic updates. So the user can select if that is what is needed for their specific project. Maybe even limit the dynamic updates to only when the APRX is opened rather than continually checking for changes if that causes issues.