nodes inside a closed way

[ghost]

Hello, is it possible to query something inside a closed way?

node(poly:"50.7 7.1 50.7 7.2 50.75 7.15"); Goes in the right direction, but the polygon is hard coded. For example: I want to ask for all amenity=bench inside(!) some forrests (landuse).

Best regards, Johannes

[mmd-osm]

If your forest landuse way comes along with a "name" tag you could in fact find amenity=bench elements as a corresponding area exists. In the following example we look for emergency access points in a forest called "Engscheider Wald" (way id = 25148854)

// Way: Engscheider Wald (25148854) - area id: add 2400000000
node(area:2425148854)[highway=emergency_access_point];out;

// Find out areas: is_in(49.4579766, 6.9936652);out;

If the name tag doesn't exist, there's no area, hence you're sort of out of luck and this approach won't work. Please take a look at the following file for more details how/when areas are created: https://github.com/drolbr/Overpass-API/blob/master/rules/areas.osm3s

BTW: How can I filter the "is_in" result for areas matching specific criteria (=e.g. have a "landuse=forest" tagging) and use this as input for the query "node(area:...)[highway=...];out;" mentioned above?

[tyrasd]

@mmd-osm like this: is_in(49.4579766, 6.9936652)->.a; area.a[landuse=forest]; out;

[mmd-osm]

@tyrasd: Thanks, that makes sense! So the query should look like this:

is_in(49.4579766, 6.9936652)->.all_areas; area.all_areas[landuse=forest]->.forest; 
(way(pivot.forest);>;node(area.forest)[highway=emergency_access_point];);out meta;

[drolbr]

By the way: Thank you for the idea.

I've just never thought about it. It would be technically feasible, at least for ways. And possible, but more demanding for relations. I put it on the "enhancement suggestions" list.

[tyrasd]

I put it on the "enhancement suggestions" list.

Nice :)

[mmd-osm]

Reading this ticket 10 months later, I realized that I somehow missed the point with this area id thing.

What @jotpe was really looking for was a mechanism to use a way id (or even a relation id) as a reference for a poly: statement instead of manually specifying all lat/lon pairs. There was also some question on help.openstreetmap.org with the same requirement.

Today, this list could be easily produced by:

[out:csv(::lat, ::lon;false)];
way(25148854);
node(w);
out;

And then put into a polygon statement: http://overpass-turbo.eu/s/6xr

But I cannot think of a good way to put this in one single statement without specifying the lat/lon pairs: e.g. way(poly:25148854,way);

Again, putting in some hardcoded way id is probably not ideal either. I would rather reuse the existing query framework and let the user use what works best. So my next idea would be something like this:

way[landuse=forest]({{bbox}})->.interesting_ways;
foreach.interesting_ways->.single_way (

   node(poly.single_way)[amenity=bench]
   out;
);

If we don't wont to clutter poly too much, we could head for a solution like this one - it has the disadvantage that sorting points is no longer possible (->actually a no-go).

way[landuse=forest]({{bbox}})->.interesting_ways;
foreach.interesting_ways->.single_way (
   node(w.single_way)->.single_way_points;
   node(poly.single_way_points)[amenity=bench]
   out;
);

Anyone got some other ideas how a sane syntax for this use case could look like?

For relations, we also need some sorting, i.e. put all ways into a sequence.

• error handling: not a closed way?

Similar ticket: #29 (could be solved by area)

[ghost]

What @jotpe was really looking for was a mechanism to use a way id (or even a relation id) as a reference for a poly: statement instead of manually specifying all lat/lon pairs. There was also some question on help.openstreetmap.org with the same requirement, can't find that one right now.

Of course.

way[landuse=forest]({{bbox}})->.interesting_ways;
foreach.interesting_ways->.single_way (
  node(poly.single_way)[amenity=bench]
   out;
);

This looks most nice to me.

error handling: not a closed way?

Ignore it. If possible: add a special tag, maybe <info>for the ignores</info>.

[ghost]

error handling: not a closed way?

Or two different methods: node(poly.single_way)[amenity=bench] breaks when the way is not closed and node(ipoly.single_way)[amenity=bench] ignores it and adds maybe a message.

[ghost]

error handling: not a closed way?

Hm, last and best suggestion: a global property like [poly:ignore_broken];, otherwise throw an error.

[mmd-osm]

Back to the help.openstreetmap.org post I quoted above, I think it would make most sense to accept 1..n ways in the inputset, which are then put together as 1 (or maybe even several?) closed way(s) based on matching start/end nodes.

Relations might contain outer and inner ways, filtering on outer ways and feeding those outer ways (might include enclaves) into the poly statement might be a reasonable use case. I don't know, if supporting relations in their own right is worthwhile or not...

[mmd-osm]

First prototype is available now in my branch.

Example 1: This example checks for amenity=bench in residential areas without name (no corresponding area object exists in this case):

[bbox:{{bbox}}];
way[landuse~"^residential$"][name!~"."];
out geom;
foreach(
  (._;>;);
  node(poly)[amenity=bench];
  out;
);

Example 2:

When the inputset contains several (connected) ways along with their nodes, we can also construct a query. In this case, the ways originate from relations' outer ways.

[bbox:{{bbox}}];
rel[type=multipolygon][landuse=forest][name!~"."];

out geom;
foreach(
  (way(r:"outer");>;);
  node(poly)[amenity=bench];
  out;
);

Relation 1736465 consists of 2 outer ways.

Example 3: Buildings on farmyards:

[bbox:{{bbox}}];

(way[landuse=farmyard];rel[landuse=farmyard]);
out geom;

foreach(
  (._;>>;);
  way(poly)[building];
  out geom;
);

Example 4: Misuse of barrier=line on leisure=pitch:

[bbox:{{bbox}}][timeout:1800];

(way[leisure=pitch];rel[leisure=pitch][type=multipolygon];);

foreach(
  (._;>>;);
  way(poly)[barrier=line];
  out geom;
); 

Germany-wide distribution:

[ghost]

Looks great! Thanks a lot! Would it be possible to publish the current branch at /interpreter_77 ? So everbody could easy try it? Regards Johannes

[tyrasd]

Seems to work quite well. Although this query seems to return quite a few superfluous elements (for example this one). This doesn't happen if one makes the bbox much smaller.

The code doesn't consider non-closed ways, does it? Are there any plans/ideas of supporting multipolygons via this mechanism as well? There are quite a lot of MPs out there where the tags are only (or also) tagged on the outer way, which would produce false positives in queries that use this a closed-way = area approximation…

[tyrasd]

so I'll probably have to drop this auto-completion again and silently ignore those non-closed ways

I'd suggest that as well, as I'm not aware of any data consuming tool does this kind of autocompletion from an unclosed way to an area. Also, what about closed ways that are tagged to be not areas (area=no)?

[mmd-osm]

Check:

• http://gis.stackexchange.com/questions/173174/query-school-elements-using-overpass-turbo
• https://help.openstreetmap.org/questions/47548/overpass-ql-return-all-parks-with-playgrounds-within-polygon

(poly:...) is not flexible enough, as it doesn't support the whole is_in and (area._) story.

We probably need for a more generic Ad-Hoc Area creation concept, which can be used like today's areas, but are only temporary in nature (i.e. they are discarded after the query finished).

[HolgerJeromin]

Just wanted to add that old style multi polygon are being cleaned up. So adding mp handling is much easier to implement than before.

[mmd-osm]

New attempt, this time using the original area creation logic:

• http://overpass-turbo.eu/s/FaP
• https://overpass-turbo.eu/s/FaQ (Example 4 above: Misuse of barrier=line on leisure=pitch)
• https://overpass-turbo.eu/s/Fbi (show all amenity=bench in unnamed residential MP)
• http://overpass-turbo.eu/s/Fbj (addr:housenumber node in building way)
• http://overpass-turbo.eu/s/Fbv (buildings without house number on the way, and as node inside building)
• https://gis.stackexchange.com/questions/315071/overpass-query-select-area-polygon-with-certain-node-in-it

[ghost]

* http://overpass-turbo.eu/s/Fbv (buildings without house number on the way, and as node inside building)

The example from @mmd-osm gives a run-time error currently:

Error: runtime error: The dispatcher (i.e. the database management system) is turned off.

Is there any update since January this year?

[mmd-osm]

The query runs on a development server that may be unavailable from time to time. As long as this feature isn't deployed to one of the production machines and publicly announced, it is not yet available for general use. Also, there's currently no timeline for this feature.

[mmd-osm]

• https://gis.stackexchange.com/questions/356973/overpass-api-query-points-not-inside-polygons/357054

[tuukka]

This functionality would be necessary for accessing various building data:

• entrance=* (not always on the building outline)
• building:part=* (a building relation is not obligatory)
• Address nodes (often not on the building outline)
• Amenities within a building (an associated_entrance relation is rare)

It might make sense to handle buildings as a special case, if a generic solution is out of reach for now.

[Wissperwind]

What is the state of the feature? I also need to querry for something like benches in the forest. As far as I understand the feature is already implemented and live on some dev server since 2019. What needs to be done to go in production?

[mmd-osm]

This issue can be closed now, solved in 0.7.57: https://dev.overpass-api.de/blog/way_based_areas.html

[gy-mate]

@drolbr @ghost Just a ping that you may close this issue.

[mmd-osm]

Ghost is a placeholder for deleted GitHub users, no need to mention them, they would never reply.

[gy-mate]

@mmd-osm Oh, thanks, didn't know that! :D I see it now on hover.