Overpass-API
Overpass-API copied to clipboard
Why do 'area' & 'name' tags affect area creation?
Hi I'm confused by this statement:
Note that area creation is subject to some extraction rules, i.e. not all ways/relations have an area counterpart (notably those that are tagged with area=no, and most multipolygons and that don't have a defined name=* will not be part of areas).
https://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL#By_area_.28area.29
My understanding is the area
tag is purely for the benefit of the renderer, & I've no idea why the name
tag is relevant.
This is purely by convention. There's a set of rules, which governs how ways and relations are treated. If they match a rule, a corresponding "area" is calculated in Overpass API by a regular batch job on the server. Only if such an area has been pre-calculated on the server, you can use it for queries such as "is a node inside an area".
In a more natural language, those rules read as: https://wiki.openstreetmap.org/wiki/Overpass_turbo/Polygon_Features
I just ran into this myself. There are a lot of missing areas simply because they don't have names. In particular, there are tons and tons of buildings that have no name themselves, but contain areas for restaurants. So is_in(some coordinate inside the restaurant)
will return the amenity, but not the building the amenity is in. I don't know why this restriction is there. This makes areas pretty much unusable for my use case.
For special requirements you have to set up your own Overpass instance, the public ones can’t offer this due to time and space constraints.
I see, that makes sense. Thank you.
Closed ways are now automatically considered in 0.7.57, the former area creation rules are no longer relevant for ways: https://dev.overpass-api.de/blog/way_based_areas.html
This requires more detailed investigation, but initially I'm confused as to why https://overpass-turbo.eu/s/1chd outputs the geometry of ways & relations.
area[name="Greenwich Park"];
out geom;
Returns 9 areas and 2 ways. You're requesting all center points for all nodes, ways and relations inside both those 9 areas and 2 ways.
OK, this appears not to be a new 'area' problem specifically. This outputs ways & relations: https://overpass-turbo.eu/s/1d38
This, just the (as expected) centrepoints. https://overpass-turbo.eu/s/1d36
Ah I see your point now, this looks like a bug indeed.
This requires more detailed investigation, but initially I'm confused as to why https://overpass-turbo.eu/s/1chd outputs the geometry of ways & relations.
Please look at the data tab. When you ask for nwr(area)
then you get for all the nodes in the tab their coordinates and for all the ways their centrepoints plus their node members. Then Overpass Turbo resolves the node references and builds node geometry. By contrast, when you ask for nwr[highway](area)
then you get few to no nodes because few to no nodes have a tag highway
and for the ways you get the centrepoints plus their nodes members. But because no node geometry is given, no node references are resolved, and all the ways are displayed by their centrepoints.
This is intended behaviour of Overpass API (because you tell it to return all or next to no nodes) and of Overpass Turbo (to ensure that a request like way[name="Greenwich Street"];node(w);out;
with unaltered OSM elements finally has full line geometry.
Ah, yes, that's an overpass turbo artifact. It reassembles ways geometries, because way nodes were also part of the output. Makes sense.