Overpass API > Blog >
Published: 2021-10-22
The Overpass API now treats closed ways not only as ways but also as areas.
The Overpass API offered areas as a derived datatype only, i.e. it computes once a day or so from the eligible ways and relations their own area data. There is a ruleset for eligibility. One problem that this process results in is that some closed ways are not available for area operations. For example, you cannot find a building that a coordinate is in, because buildings in general are not converted to areas.
The near future brings a second source of trouble: There will be collisions between the potential ids of way based areas and relation based areas. That means that it may happen that an area cannot be computed because its id is already occupied by another derived area.
More in general: areas interact properly with far fewer statements than nodes, ways, and relations. That special rules are somewhat annoying. Finally, the way based areas occupy precious disk space on the servers.
For that reason, the software has been enhanced to treat closed ways as areas as well. This means that for this type of areas the Overpass API can offer the full set of operations. It also allows to remove the way based derived areas immediately from the database.
The statement is_in returned only the derived areas, but now it also returns closed ways. The filter (pivot) looked only at derived areas to return their original objects, but now it also relays closed ways from input to output.
Thus, this preferred sequence of statements works in all versions:
is_in(51.478,-0.001); wr(pivot); out geom;
In the old semantics, the is_in statement found the derived areas, and the (pivot) filter then looked up the generating ways and relations. In the new semantics, the is_in statement finds the derived areas and closed ways, and the (pivot) filter then looked up the generating relations and in addition keeps the closed ways.
As a result, the existing areas continue to be found. In addition, closed ways that were not covered by a rule are now also found. Good examples for this are buildings, playgrounds, and landuse polygons.
There might be some corner cases where a closed way shall not be found as an area. Mappers are instructed to set a tag area=no on such an object, and the following query would exclude such closed ways:
is_in(51.476,0.0459); area._[area!=no]; out geom;
Please remove the [area!=no] part to see the difference!
While I do not recommend the following sequence of statements, it continues to work:
is_in(51.476,0.0459); out tags;
Please note that out geom in place of out tags never worked because the areas have no geometry associated to them. While out geom now works for the found ways, it still does not work for areas derived from relations. Nonetheless, the statement out tags does deliver the tags of the covering areas. It used to display tags from derived areas and now does so from both closed ways and derived areas.
The following sequence of statements is anyway discouraged and changes its behaviour:
is_in(51.476,0.0459); out ids;
As a side effect of the semantics change, the internal rules for numbering derived areas have changed.
A query statement with type area returned derived areas in the past, now it returns in addition also closed ways. In line to this, the filter (area) evaluated in the past derived areas, and now it evaluates in addition also closed ways. The statement map_to_area continues to resolve relations to their derived areas, but it now lets closed ways pass instead of resolving them to derived areas.
Thus, this preferred sequence of statements works in all versions:
area[name="Greenwich Park"]; nwr(area); out center;
In the old semantics, the statement with area datatype had found only derived areas. Then the area filter selects the objets based solely on derived areas. In the new semantics, the statement with area datatype finds in addition also closed ways. Then the area filter selects the objets based on both derived areas and closed ways. As before, all objects inside are selected.
The change is that now all closed ways can be relied on, not only those matching the area generation rules.
Now the following query is possible:
area[name="Greenwich Park"](51.47,-0.01,51.48,0.01); nwr(area); out center;
However, even in the new version it still only works for closed ways. Derived areas are never found by the bounding box filter. The following alternative should work in both new and old versions instead. Opposed to the request before, it applies the bounding box to ways and relations and computes the areas based on that result:
wr[name="Greenwich Park"](51.47,-0.01,51.48,0.01); map_to_area; nwr(area); out center;
The following query is discouraged and exhibits in both version different behaviour:
area(24004483968); nwr(area); out center;
Please do not compute the area ids yourself. I do reserve the right to change how the id is computed, and exactly for this reason the behaviour now changes: While way based areas used to get their id by adding 2.4 billion to the way id, the relevant id is now the way id itself. Instead of this request, the following variation is recommended:
way(4483968); map_to_area; nwr(area); out center;
This works in both versions. No id computation on the side of the user required. It now works for more ways.
Would it make sense to also process relation based areas solely by their representation as relation? Definitely yes. Unfortunately, there are many more large scale relations than large scale ways. Thus, the algorithms used for closed ways are unlikely to work as well for relations. Relations can only be directly treated as areas if their format in the database is changed such that it is easier to get the coordintes that they cover.
For this reason, this not not happening now, but postponed to a version where the internal database format changes anyway.