2

I want to select all polygons with

tourism=camp_site and tourism=caravan_site without the key 'sanitary_dump_station'

but where a node is located inside the boundary with the tag

amenity=sanitary_dump_station

I tried different approaches and ended up with this:

 [out:json][bbox:{{bbox}}][timeout:120];

node ["amenity"="sanitary_dump_station"] ->.a;
.a is_in ->.b;
way(pivot.b)->.x;
way.x["tourism"~"caravan_site|camp_site"][!"sanitary_dump_station"]->.z;
(.z; .a; );
out geom;
>;
out skel qt;

In the results I find some campings without the key 'sanitary_dump_station', eg.: https://www.openstreetmap.org/way/116540519#map=19/50.22837/1.61213, while there is a node within its boundaries (https://overpass-turbo.eu/s/GRl)

Improve this question

1 Answer 1

Reset to default
2

This will not work with arbitrary polygons as of today, or to be more precise, there has to be a matching area created beforehand on the server, subject to specific area creation rules. Those rules usually require a name tag to be present on the respective polygon.

You can use the following query, which depends on the existence of areas. Effectively, this means that your camp or caravan site has to have a name=* tag - otherwise no corresponding area exists on the Overpass API instance and you will get incomplete results, similar to your experience with is_in in your question: https://overpass-turbo.eu/s/GRE -

This issue is currently being tracked in https://github.com/drolbr/Overpass-API/issues/77 and at this time there's no official solution available yet to analyze camp/caravan sites without a name, where no corresponding area exists on the Overpass instance.

However, you can try the following prototype in the meantime, which creates areas on-the-fly and is not bound by the mentioned area creation rules on the server: https://overpass-turbo.eu/s/GRB - (for testing purposes only)

Improve this answer
11
  • As I understand well. The problem is due to the lack of a name? And when I try both - my query and your sollution - they gives the same result... Which one is then the 'better' one?
    – PieterB
    Commented Mar 11, 2019 at 21:14
  • I'm not sure I understand your second question, can you elaborate a bit what you're trying to achieve with that random name and why do you need it?
    – mmd
    Commented Mar 11, 2019 at 21:52
  • The root cause for this behavior is that way 116540519 doesn't have a corresponding area on the Overpass API instance, hence is_in doesn't return an area. Official Overpass instances don't support this kind of ad-hoc area creation yet. That's what GIthub issue #77 is all about. Bottom line: your query doesn't work the way you intend it to work. In your example overpass-turbo.eu/s/GRl - the inputset .z is even empty, so results of that query are fairly random and don't match your requirements at all.
    – mmd
    Commented Mar 11, 2019 at 22:05
  • 1
    Query overpass-turbo.eu/s/GRE starts by finding all campsite ways first, finds a corresponding area by using map_to_area;, then iterates over each single area and tries to find all amenities inside each area. Your query works the other way around: you find determine all amenity nodes, and try to find out if they are inside a campsite way. The reason why I modeled the query this way was the prototype query overpass-turbo.eu/s/GRB, where I cannot use is_in;. I tried to make my two queries as similar as possible to each other so it's easier to see what's happening.
    – mmd
    Commented Mar 13, 2019 at 10:18
  • 1
    No, that's not clear yet, and a bit related to the nature of a prototype.
    – mmd
    Commented Mar 14, 2019 at 8:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.