Skip to main content
16 events
when toggle format what by license comment
Mar 14, 2019 at 8:45 comment added mmd No, that's not clear yet, and a bit related to the nature of a prototype.
Mar 13, 2019 at 19:14 vote accept PieterB
Mar 13, 2019 at 10:53 comment added PieterB OK, now I understand your logic. But as I understand well from your answer: I cannot use that prototype. Any idea when it will be released?
Mar 13, 2019 at 10:18 comment added mmd 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.
Mar 12, 2019 at 12:11 comment added PieterB I did read your answer! And I'm glad that you want help me. Perhaps there is a misunderstanding about the overpass-turbo.eu/s/GRE. I did not write that, because I'm not familiar with the foreach-clause.
Mar 12, 2019 at 11:56 comment added mmd Did you actually read my answer? That's exactly what I have written: 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: overpass-turbo.eu/s/GRE -
Mar 12, 2019 at 11:51 comment added PieterB As far as I can see: my query: overpass-turbo.eu/s/GSG no result, your queries: overpass-turbo.eu/s/GRE no result, overpass-turbo.eu/s/GTO gives result.
Mar 12, 2019 at 11:03 comment added mmd Again, results will be different, and depend on the existance of a name=* tag on the surrounding way. If you're happy to accept incomplete results (which don't include any campsites without a name), then there isn't much I can do about it and we can stop here. Can you easily spot that your query returns a different result by comparing your query overpass-turbo.eu/s/GSZ (returning no result) with prototype overpass-turbo.eu/s/GT0 (finds a result). Also your query doesn't find way 652040499 with Node 6113645896 inside.
Mar 12, 2019 at 8:38 comment added PieterB the inputset .z is empty because of the fixed boundingbox which should be returning the camping without the name. But when you set it to {{bbox}}(overpass-turbo.eu/s/GSG) it gives me the same results als yours
Mar 11, 2019 at 22:17 history edited mmd CC BY-SA 4.0
added 34 characters in body
Mar 11, 2019 at 22:11 history edited mmd CC BY-SA 4.0
added 34 characters in body
Mar 11, 2019 at 22:05 comment added mmd 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.
Mar 11, 2019 at 21:52 comment added mmd 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?
Mar 11, 2019 at 21:14 comment added PieterB 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?
Mar 11, 2019 at 17:00 history edited mmd CC BY-SA 4.0
added 273 characters in body
Mar 11, 2019 at 16:47 history answered mmd CC BY-SA 4.0