Zoek alle amenity=place_of_worship waarbij niet binnen 50 meter een building is van het type church, chapel of mosque. Mooie manier om de building types te verbeteren.
Voor voormalig kerkgebouwen lijkt het ook de bedoeling om dan nog steeds het gebouw als kerk te taggen.
Merk alleen dat als je ook de amenity veranderd in disused:amenity het icoontje weer wegvalt.
En nog even een testje om de twee methodes te vergelijken.
Links overpass, rechts openpoimap.
De 4e kerk in het rechterplaatje (Thomaskerk) komt er in de overpass niet uit.
Misschien de grens op 5 meter zetten?
Marc, dit zijn toch iets andere zoekopdrachten.
Place of worship wordt regelmatig ook getags als een losse node terwijl het gebouw een way is. Zonder de around functionaliteit kun je dit nooit aan elkaar linken om te zien de building onterecht op yes of house staat.
Die 50 meter was willekeurig gekozen eigenlijk en kan wellicht korter
De Thomaskerk komt in de Overpass dus niet tevoorschijn omdat het onderliggende gebouw dus wel netjes een church is.
Er komt trouwens nog een interessante zoekoptie aan in overpass. Zoeken binnen een area. Alleen heb ik gemerkt dat soms de amenity nodes net buiten de building liggen, dus dan heb je er ook weinig aan, maar mogelijk wel inzetbaar voor andere zaken.
Zie overigens wel dat Vrijburg ontbrak, terwijl deze building ook slechts yes is. Daarop de overpass query iets aangepast: http://overpass-turbo.eu/s/8FN
Daarbij gebruik ik jouw voorstel om een negatieve waarde als trigger voor deze functie te gebruiken.
Let op: de tag vóór het eerste haakje mag gewoon met een “=” worden opgegeven, de tag na de haakjes moet als regex worden opgegeven.
Met taglocator zie ik dan dit in scheveningen:
Doe ik de overpass-turbo met dezelfde data, dan zie ik dit:
Er is dus nog een verschil tussen beiden.
De code die ik in taglocator gebruik komt rechtstreeks uit de door overpass-turbo gegenereerde “bevraging”.
Dat zie er zo uit:
Marc, zo op het eerste gezicht lijkt de geconverteerde zoekvraag dezelfde uitkomst te hebben als de oorspronkelijke query als je die direct uitvoert. Kijk straks nog wel even of ik de bevraging van taglocator kan bekijken of het in het weergeven van de data zit of in het ontbreken van data.
De data blijkt dus exact hetzelfde, dus blijkbaar ontbreekt er iets zodat het in openpoimap niet weergegeven kan worden. Zo te zien verschijnen enkel de nodes en niet de ways.
Vergelijkend met de data die uit de andere queries komt lijkt de center lat/lon te ontbreken.
Als je na de laatste out “center” toevoegd, komt die ook weer netjes in de data terrecht. Dan kan het icoontje hopelijk ook getekend worden op die positie, want dat zal het issue wel zijn vermoed ik zo.
Dat was het!
Ik gebruik nl de door Gertjan Idema gemodificeerde FormatOsmExtended.js waarmee je de icoontjes netjes binnen de contouren van een gebouw krijgt.
De huidige taglocator (nog steeds 1.05+++) bevat de gewijzigde code en kan dus worden getest…
Ik merk nu wel dat de door jou bedachte code heel specifiek voor die situatie geldt, met ways en nodes.
Want als je bv. zoekt naar een restaurant (als node) dat zich niet binnen een afstand van 50 meter van een ATM (ook als node) bevindt, en voert dit in:
amenity=restaurant(-50)'amenity'~'atm'
amenity=atm
amenity=bank][atm][atm!=no[/code]
(de laatste 2 regels om duidelijk te maken waar de ATM is te vinden),
dan werkt dat niet zoals je zou verwachten.
De geldautomaat bevindt zich op ongeveer 100 meter afstand.
Welke afstand ik ook gebruik, altijd krijg je dezelfde uitvoer.
En ook overpass doet dat (situatie in Venlo):
Met 10 meter:
[url]http://overpass-turbo.eu/s/8HL[/url]
Met 300 meter:
[url]http://overpass-turbo.eu/s/8HM[/url]
Dat beketent dus dat de huidige code zeker nog niet universeel is voor alle gevallen [b]A[/b] [i]niet binnen afstand x[/i] van [b]B[/b].
Of zie ik iets over het hoofd?
Edit:
Ik heb jouw overpasscode aangepast en krijg nu wel het verwachte resultaat:
[url]http://overpass-turbo.eu/s/8HP[/url]
Maar dat betekent dat het heel lastig wordt om een robuuste manier te krijgen voor taglocator.
Je moet dan een uitgebreide parser maken om te zien wat de gebruiker precies vraagt.
Je zou dus wel een basisversie kunnen maken die alleen naar nodes kijkt.
Voorlopig nog een work in progress..