Je mag als mapper wel zelf kiezen welke methode je hanteert (node of vlak), maar het is niet de bedoeling dat je details verwijdert om een voorkeursmethode te verkiezen. Iemand die zoekt naar de tennisvereniging in Stiens ziet nu het hele terrein. Alleen een node ergens op dat terrein tonen is een achteruitgang qua data, en dus niet wenselijk.

Nee, dat is niet mogelijk. In OpenStreetMap kunnen zaken op nodes, lijnen, en vlakken getagd worden. Wanneer een vlak gebruikt wordt, is er meer informatie beschikbaar (de grootte van het terrein bijvoorbeeld, en welke buitenbanen daar in liggen).

Je zal voor het uitlezen dus rekening moeten houden met zowel nodes als vlakken.

Leeuwarden heeft ook nog eens een situatie waar het terrein gedeeld wordt door twee clubs (eigenlijk dezelfde, maar verschillende namen en identiteiten). Daar is het opgelost door de faciliteit (leisure=sports_centre) op het vlak te taggen, en de twee clubs met club=sport op nodes. Dat is echter een uitzondering (waar je ook rekening mee moet houden).

Die van Stiens klopt zo toch?

De tag building=yes hoort sowieso niet op een terrein. Waarom deed je dat op meerdere plaatsen?

Soms is een sportterrein al als vlak getagd. Het is dan niet juist om die data te verwijderen en op een node te zetten. leisure=sports_centre is voor een multifunctioneel gebouw of een sportterrein. Als die door meerdere clubs gebruikt wordt moet je de club los van het terrein mappen, maar dat is niet nodig wanneer er maar één club is.

Ook hier maak je een gebouw van een terrein (teruggedraaid).

Hey! Lees je mail eens voor je verder gaat! Je maakt hier ook een gebouw van een terrein.

Dit gaat niet goed. Je maakt een gebouw van het hele terrein, en verwijderd tags van een vlak om ze op een node te zetten. Waarom?

Het is wat dubbelop, want het hele terrein is al aangemerkt als sportclub:

way/721620771

Op de node hoeft dus geen informatie.

This area currently duplicates the BeNeLux. What is the meaning of this entity? Europe/Brussels can refer to one of these:

* Alias used in Belgium for the timezone it uses (currently CET/CEST).

* Alias for CET/CEST.

* Alias for UTC+01:00.

This relation is none of the above, and appears te combine the timezone aliases Europe/Amsterdam, Europe/Luxembourg, and Europe/Brussels; all of which point to the much larger standard time of CET/CEST.

I can't find any justification for keeping this relation, and intend to delete it. My assumption is that it was created based on a misunderstanding of the cluster of countries in tz-database.

By the way: OsmAnd renders ruins:building (and other prefixes) just fine. Don't focus on Carto (which is pretty much unmaintained) too much.

If you're using this church in a back-street next to the huge landmark of the Vondelpark to navigate by, you have bigger problems.

Don't worry: in a few months/years it will probably be a building again:

https://nos.nl/artikel/2596704-eerste-bewoners-terug-naar-huis-na-brand-vondelkerk-goede-hoop-op-herstel

Different mapping strategies exist. If the tags used here were wrong you'd have a point, but they are not.

andrewsh: We would be retagging all highway=busway and landuse=education to highway=service and amenity=school by that argument (because Carto doesn't render those). Doing that is not the consensus.

TrickyFoxy: yeah, I've looked at entities with only a ruins:building:

way/888868619

Nominatim seems to be broken for those.

Current status is that the thing burned down; the tagging reflects that. What happens next is up to the municipality, and not relevant to this discussion.

Someone got here before you and used tags you wouldn't have. However, those tags are valid, and using them is one way to get support for them improved.

When the next church burns down, see if you can be the first to edit it, and use the tags you used (which are also valid).

Those counter-examples are based on the assumption that the tag used is not popular and incorrect. For lifecycle-prefixes this is false on both counts.

Don't tag for the renderer. File bugs with them if you want them to support it.

Lifecycle prefixes are broadly used and are valid tagging. If someone chooses that approach, redoing their work is not appreciated.

Waarom? Er is niks mis met ruins:building. Lifecycle prefixes zijn breed gedragen en goed gedocumenteerd.

Teruggezet naar de versie van TrickyFoxy.

Nee klopt. Algemene nummers horen daar niet thuis.

Ik zie het nummer wel staan bij Zwolle, maar Amsterdam noemt geen nummer.