360 keer is best veel voor een ongedocumenteerde tag. Ik heb hem nu gedocumenteerd.

Blijkbaar achten mappers die tag nodig.

En let even heel goed op! Verwijder oneway=no niet zomaar! Daar zijn al vaker discussies over geweest. Die tag wordt namelijk ook gebruikt op plekken waar goedbedoelende mappers per ongeluk oneway=yes toevoegen. De tag oneway=no is een signaal aan mappers om even twee keer na te denken.

Je houding neigt naar vandalisme. Kap daar mee.

Je bent al even bezig met meerdere changesets trouwens. Heb je noname=no vaker weggehaald? Pas je werkwijze aan, want je hebt dan waarschijnlijk op meer plaatsen mappers-hints verwijderd.

Jouw aanname dat noname=no niet samengaat met name=* klopt niet. Het is andersom: noname=no vereist name=*.

Deze wijziging had zich moeten beperken tot noname=yes die inderdaad geen name=* mag hebben.

Wat is er mis met noname=no? Die tag wordt nog best vaak gebruikt ook. Zet je die ook terug?

Please restore the tags on:

way/754391305

And:

way/754391318

You removed a note and noname=no. They are there for a reason, because while roundabouts are often unnamed, these are named with signs and all. That note (and noname=no) is there to inform overeager mappers that this is correct.

Dit dupliceert de al aanwezige data. Dat is niet de bedoeling. Dat is het principe van één ding, één element:

osm.wiki/One_feature,_one_OSM_element

Zie Leeuwarden voor een voorbeeld waar twee nodes wel nodig zijn omdat de faciliteit en de clubs daar niet hetzelfde zijn. Hier is dat niet het geval (meestal is dat ook niet zo).

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.