natural=sand vertägt sich nicht mit leisure =playground. Man könnte surface= benutzen, ist aber auch nicht wirklich besser. Anders augedrückt ein Spielplatz wird in grün gerendert und nicht gelb.

landuse=recreation_ground ist nicht der richtige Tag für ein Sportzentrum. Wenn hier unterschiedliche Sportzentren sind können wir die auch einzeln mappen und am besten auch benennen.

"shop=pharmacy" is rejected, so we should use "amenity=pharmacy" instead.
Best Regards,
Dieter

Ok resort is correct in this place. But you should add the buildings with tourism=hotel.

Die Schlüsselnummer wird im Amtsblatt erwähnt, aber OSM benötigt sie nicht.

Ja ich habe es inzwischen auch gesehen die Straße ist noch im Bau. Aber danke für den Hinweis

Ich habe es korrigiert. Ich hoffe es ist so OK sonst ändere es bitte.

Da es massenweise Beispiele für Haltekanten gibt, welche von schienengebundenen und nicht schienengebundenen Fahrzeugen gibt wurde dieses Tag durch public_transport=platform ersetzt.
Original Wiki

Gewöhnlich werden in einem Änderungssatz mehrere verschiedene Änderungen gemacht, die kann man nicht noch einzeln erklären.
Auch ist es unüblich alle Änderung vorher in einem Forum zu diskutieren. Da gibt es immer jemand der ein Bedenken äußert. Und zum Schluss kommt keiner der ein Resümee zieht.
Ich verstehe auch den Grund nicht warum highway=bus_stop irgendwie in Frage gestellt wird. Solange public transport platforms nicht gerendert wird ist das doch wohl der wichtigste tag für eine Bushaltestelle (Siehe https://github.com/gravitystorm/openstreetmap-carto/issues/311).

highway=bus_stop muss auf jeden Fall seitlich am besten da wo das Haltestellenschild ist. Sonst wird die Bushaltestelle mittig gerendert und man weiß nicht für welche Richtung die Haltestelle zuständig ist. Wenn du schon Bussteige einzeichnen willst nimm der vorderen node in Fahrtrichtung für das Schild mit name usw. Im Rest von Berlin hat sich das schon bewährt.

Du hast recht ich finde es aber spontan nicht wieder.

Der tag brand ist im Zusammenhang mit post_box nicht zu verwenden, da operator schon aussagt, wer der Betreiber ist.

megalith_type =standing_stone was not described in the wiki. So I assumed it would be a menhir. As I have read more about it, it can also be a historic=stone. Maybe I must also revert it?

Stimmt hier gab es keine klare Linie. Über das Schema kann man geteilter Meinung sein. So war es der kleinst gemeinsame Nenner der ins OSM-Schema passt. Abgesprochen habe ich mich mit Wiki- Aktiven direkt. Es gab beacon=airmark, navigationaid, navigation_aid, man_made=beacon für Flugnavigationsfunk wie VOR, ILS, NDB usw. Das Forum hätte für dieses fachliche Thema nicht weiter geholfen.

Ich kannte das Netto-Problem bisher noch nicht. Unter den gegebenen Umständen bin ich auch dafür den „Netto mit Hund“ in Großbuchstaben zu schreiben. Werde also in der Zukunft meine Augen diesbezüglich offen halten.

Namen sollen immer mit einem Großbuchstaben beginnen und danach nur kleine Buchstaben. Mache Firmen / Geschäfte benutzen nur kleine oder große Buchstaben. OSM unterstützt diese Akzentuierung nicht. Für operator=* mag es andere Regeln geben.

Du hast recht, eine WMS-Layer habe ich auch nicht mehr gefunden. Aber auf der seite FIS-Broker der Layer Hauskoordinaten oder Karte von Berlin 1:5000 zeigt die Hausnummern. Vielleicht ist source=Geoportal Berlin / Hausumringe nicht die beste Bezeichnung. Gruß

Ich habe mich rein auf die schon existierenden OSM-Tags bezogen. Ja, ich habe die Objekte einzeln bearbeitet. (Bei manchen war die Frequenz in kHz statt MHz angegeben, bei anderen fehlte die Einheit)

Dem könnte ich zustimmen. Wäre nur schön wenn die Wiki-Seite Tag:aeroway=navigationaid und Key:navigationaid das noch besser erklären könnten. Wobei die Radionavigation (VOR, DVOR, DME usw) besser bei Tag:airmark=beacon aufgehoben sind und hier wegfallen sollten. Gruß

Moin, dann sehe ich es so, dass wir für diesen Fall noch keinen Tag haben. man_made=beacon ist auf jeden Fall unpassend. Gruß