How many features do you need to see in your average feature layer? Yes, I’ve asked you an impossible question with no context. But regardless of the answer, you can always change that answer with a definition query.
If you don’t know about them, definition queries are statements that declare which features in a layer draw on a map. Definition queries are expressed in the SQL language, which has its own set of rules in ArcGIS.
To show how definition queries can be useful, I am designing a map of northwest France. I have a polygon feature class of French administrative regions, and a web service of European cities. If I have a field in the service that includes the region each city is located, I can construct a query to limit the features drawn to my area of interest.
The ‘Northwest France’ definition query’s “WHERE” clause (in reference to SQL), or attribute clause, would look something like this:
WHERE “region” IN (‘Bretagne’, ‘Normandie’, ‘Pays de la Loire’)
Thus, if the city feature’s region field does not equal one of these 3 values, the feature is not drawn. However, the dataset doesn’t have a region field… Zut!
We need to filter out cities like St. Helier and St. Peter Port, which are prominent in the map but are ‘British’ cities. I also want to filter out French cities like Orleans and Poitiers, so filtering by country doesn’t work either. The number of features is small enough that I could manually work through this issue, but I want an extensible workflow.
Spatial clauses
Starting with ArcGIS Pro 3.5, you can solve issues like this with a spatial clause. It opens the door to filtering features by their spatial (geographic) attributes. Traditionally, (definition query) clauses must specify which features draw using field names and value ranges. This particular spatial clause starts with a WHERE declaration but uses spatial geometries to determine which features draw instead.
But what’s a spatial geometry? Simply put, it’s the area of interest. The spatial clause expression uses geometry – such as the spatial extent of the map, selected features, or the features currently in view – as its search area. The query parses the dataset for overlapping features and draws any feature that intersects the search area. Features outside the search area are not drawn.
This is great, because we have our feature layer of regions. I can select the three regions of interest, then construct a definition query on the cities layer to filter it to this area.
The resulting spatial clause looks like this in ArcGIS Pro:
WHERE Shape is intersected by <Geometry>
This oversimplifies what’s going on, but you can think of “Shape” as the feature type (point, line, polygon, etc.) and “Geometry” as the spatial area we’ve determined. In this case, it is our three administrative regions.
To summarize: because we don’t have city data with a region field, but have a dataset of administrative regions, we can use the selected polygon features as our ‘spatial geometry’ to filter out any cities outside the selection.
I used this simpler example to demonstrate what can be accomplished. Do let us know if you’d like to see a more advanced example in a future post, and how you plan to implement spatial filtering into your workflows. Until then, happy mapping!
Credits: Administrative region data courtesy of Esri France. Basemap is National Geographic Style Base.
Hello, this is a very interesting improvement.
Is the spatial filter dynamic in the “selected feature” case, as shown in the article ? I mean, if I select another region on the map, will it automatically filter the cities that intersect it?
hello @Pierreloup Ducroix, we are glad to know that you have found this enhancement interesting.
Currently, search geometries used in spatial clauses are not dynamic. They are copied by value and those geometries are stored with definition queries. There are no references maintained to the layer from where you picked those search geometries. That is why changing selected features won’t affect the definition query.
We find your idea interesting. Would you mind log a new idea on this site? https://community.esri.com/t5/arcgis-pro-ideas/idb-p/arcgis-pro-ideas
That way we can gather more requirements to make further enhancements. This is our first release with spatial clauses, and we are hoping to roll out more exciting and useful enhancements in the future. Please keep sending us your requirements.
Hi, when do we expect this to be supported by the server (Web Map)?
hello @Yazan Sbeih
Unfortunately as of now we don’t have any specifics on the time line. Could you pls enter an idea on Esri Ideas site: https://community.esri.com/t5/arcgis-pro-ideas/idb-p/arcgis-pro-ideas with some details about your workflow?
Thank you.
A great addition to the Definition Query function. Is there a planned update to support more Select By Location capabilities? Specifically interested in Relationship types and inversing the selection for potential QC applications.
Hi Joseph – thanks for your question. We have goals to support more than ‘Intersect’, which is the sole supported operator in ArcGIS Pro 3.5. I would request that you submit a comment to the ArcGIS Ideas page at the Esri Community forum (https://community.esri.com/) and express your use cases there. Providing details on how you would use spatial querying in your work if it included more capabilities from the Select By Location tool will go a long way. Thanks! – Greg