Oh Dear.
I've always been hesitant to call out specific contributors by name, but
user 'mentor' has been a repeated thorn in my side whenever he's (male?)
'contributed' in my locale. Those edits can, at best, be described
'assumptive' (either that, or he's widely travelled within the UK,
whilst blindfolded).
For this specific example: From aerial images, I would tag the whole
area, including rear patio area/car parking as amenity=pub, name=* etc &
combine the full extent of the building as building=pub. Both relations
appear unnecessary.
Additionally the residential area could be tweaked around the shops/pub
& landuse=retail be added.
Your 2nd point:
Coincidentally I've just noticed that it only returns the first option
(swap nodes with ways to see). I'm unclear if it's by design or a recent
update error. I'd be interested to know the answer.
Try:
{{geocodeArea: Brighton and Hove}}->.searchArea;
(
node["amenity"="pub"](area.searchArea);
way["amenity"="pub"](area.searchArea);
relation["amenity"="pub"](area.searchArea);
);
(._;>;);
out body;
DaveF
On 24/10/2017 17:35, Jez Nicholson wrote:
Just preparing an Overpass query for the OSM workshop I am running in
Brighton. Naturally I queried pubs....then wondered whether I need
bother with relations....and found
http://www.openstreetmap.org/relation/3216899
Seems a bit of a sledgehammer to crack a nut.
While i'm here, can anyone tell me why
http://overpass-turbo.eu/s/szG does not return nodes and
ways-and-their-nodes? It is very similar to the example
area[name="Brighton and Hove"][admin_level=6];
(
node(area)[amenity=pub];
way(area)[amenity=pub];
);
(._;>;);
out body;
- Jez
_______________________________________________
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
_______________________________________________
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb
