Gebedshuis zonder passend gebouw

Op basis van de query uit het openpoimap topic.

Bijvoorbeeld deze http://overpass-turbo.eu/s/8DO

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.

Is dat niet wat omslachtig (en onnauwkeurig)? Want waarom die 50-meter grens in jouw vb.?

Als ik dit doe met de userpois:

amenity=place_of_worship]['building'~'chapel|church|mosque|temple|synagogue|cathedral'
amenity=place_of_worship]['building'!~'chapel|church|mosque|temple|synagogue|cathedral|yes'

Dan zie ik:
(1) alle gebedshuizen mét building=* en
(2) alle gebedshuizen zónder building=*

En die laatste groep is in de meerderheid! Werk aan de winkel!

Edit: “yes” toegevoegd aan 2e coderegel om het resultaat nog beter te maken.

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

Helemaal mee eens!

Inderdaad, daarom weer een testversie ingebouwd in taglocator 1.05+++.
Met een afstand van 10 meter getest middels deze opdracht in userpois:

amenity=place_of_worship(-10)'building'~'chapel|church|mosque|temple|synagogue|cathedral'

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:

"?data=(node(bbox)[" + keyValues + "];way(bbox)[" + keyValues + "];)->.allnodes;((way(bbox)[" + aroundKeyValues + "];)->.poi;
(node(around.poi:" + around + ")[" + keyValues + "]->.result;way(around.poi:" + around +")[" + keyValues + "]->.result;
way(around.result:" + around + ")[" + aroundKeyValues + "];);)->.nearnodes;
((.allnodes; - .nearnodes;);way(bbox)[" + keyValues + "][" + aroundKeyValuesNeg + "];);(._;>;)->.notnear;.notnear out;"

keyValues: amenity=place_of_worship
aroundKeyValues: ‘building’~‘chapel|church|mosque|temple|synagogue|cathedral’
aroundKeyValuesNeg: ‘building’!~‘chapel|church|mosque|temple|synagogue|cathedral’

Kun jij verklaren waarom er een verschil in uitvoer is?

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.

https://github.com/drolbr/Overpass-API/issues/150 is trouwens ook wel een interessante enhancement request. Zou je backend behoorlijk kunnen ontdubbelen voor node/way/relation.

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…

We zien elkaar zaterdag!

@Sander:

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..