Thank you pnorman tekim and turepalsson. I went digging through my old software engineering from several years ago, and this is the more complete answer I was searching for:
- While OSM does not have the concept of layers its analogous concept is simply to return nodes, ways, and areas within a prescribed bounding box.
Here are the National Parks in a large region of the western US.
Here are the buildings in and around Bern, Switzerland (narrowed to a random suburb to limit its length for demonstration purposes).
Here are the fire stations in and around Bern, Switzerland.
We can see that in each of the OverpassAPI calls, the
nwr query is applying a selector filter
["amenity"="fire_station"] and subsequently querying only within the bounding box
out geom simply refers to the format for the output.
is_in does exactly what was specified by you three. There are a few caveats that I feel are worth mentioning. The
is_in key attribute (which actually comes up first in web searches and produces about a dozen sub-sets) is a mostly deprecated, transitory field of manually added string fields to associate with the node. This is not what any of us were referring to nor the solution to this question. The
is_in query subsequently does exactly what was specified by you three: searches for every way and area for which the
lat,lng encloses. (And ways and areas, when categorized by an attribute, are equivalent concepts to layers in other languages.) This is the base of the correct solution.
Here are all the ways and areas that a specific point near the summit of Grand Teton is in, including administrative layers (names of counties), national parks, time zones, and all other layers in the database (one for a nearby point simply specifies ‘rock’ referring to an amateur inclusion of the geologic surface layer as added to the database).
Here is the same
is_in query applying the filter returning results of national parks:
A key insight for wayward searchers who arrive here is that
is_in is very fast to filter and I was delighted by this. Because the
is_in provides results for every potential boundary the return set can be huge and extensive; filtering after the
is_in query is, however, the expected way to perform these OverpassAPI searches.
Here is a point known to be in a
building near Bern, Switzerland, and how to identify whether the point is inside a building, as per whether the query returns any results. In this case we discover the building is a
And, if you are a wayward traveller searching out for a
barn on their quest for a hobo paradise to spend the night you can filter for barns in this way:
As I said, the filtering is very fast and the expected design of the OverpassAPI. The alternative would be to first query all barns in a region and filter by one specific
lat,lng, and could be faster were the API and database constructed differently.
Thank you so much for everyone who chipped in to help, and I hope this solves what future web searchers need when they find this page. Please feel free to reach out to me by email now or in the future for any additional questions, future web searchers.