nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

Find more posts tagged with

Map Authoring

Under Consideration

Status: Under Consideration

Comments

TravisColeHC

At our County government, data is constantly evolving—areas are annexed, section corners are surveyed and updated, tax districts are revised, and many other layers change regularly. Making these spatial queries dynamic would be extremely valuable, allowing us to apply them to specific layer types and meet the needs of various corporations or county departments that simply want their data displayed without the rest showing.

Currently, I have a specific need involving planning districts. I need to query a single planning district for one of the corporations in the County, but I also want that query to remain dynamic so that if the boundary changes, the data automatically reflects the update.

Cory__Williams

Adding dynamic capabilities to this function would be extremely useful, in conjunction with Map Series! We often have to map features using Map Series, but the data is not linked by attribute. Which results in us having to create additional datasets to cater for this, or manually re-doing the spatial query.

Having the ability to have a map series, which will only capture features within the polygon that we are wanting to show would be extremely useful!

TanuHoque

thank you all for your quick responses.

JoshuaBixby

@TanuHoque , thanks for chiming in on this discussion and for considering the idea. @DavidFotheringham1 , thanks for posting the idea and getting the discussion wrong. I am always open to being wrong, even happy at times about it, when it means improvements come quicker than I expected.

RTPL_AU

@TanuHoque
I typically use many data sources at the same time. Local data is in network shared FGDBs most of the time.

DavidFotheringham1

For me the datasets could come from multiple sources. Not just a single
database. Some may come from local geodatabases. Some might come from
online hosted feature services. It would be good to have flexibility to use
any source and not just restrict to those layers with the same source.

TanuHoque

thank you all for adding your workflows... I hope you will get more workflows from others in the future. As you might have noticed, this idea is under consideration. We will look into the feasibility of this functionality and see what we can do about this.

Quick question - are you datasets stored in a single database? or they may come from multiple workspaces?

ZachBodenner

Even if it was an option in the definition query window to enable this behavior, that would be nice. @JoshuaBixby is definitely right about the compute-intensivity, but I suspect that I might be working with some of these soon, with small enough datasets that it would be not trivial to use them, but also not debilitating to run dynamically.

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.

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!

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?

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?

mvolz47

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?

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.