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.
Article Discussion: