Hallo Reiner,
Fehler passieren halt, und je öfter man editiert, desto öfter kann etwas schiefgehen. Und ja, in der Tat können die Editoren leider auch nicht alle Fehler finden. Merkaartor, den ich verwende, validiert gleich so gut wie gar nichts. (Andererseits versucht er selbst, die Multipolygone zu rendern, da könnte einem der Fehler optisch auffallen. Aber dafür gibt es andere Fehler, die ohne Validator überhaupt nicht bemerkbar sind.) JOSM gibt sich da eh schon vergleichsweise viel Mühe, Dinge zu validieren.
Und das Fiese ist ja auch, daß der Fehler dann in der Regel nicht sofort im Mapnik-Rendering aufscheint, und erst noch später im OSM Inspector.
Also alles kein Vorwurf. :-)
Liebe Grüße,
Kevin

Leider hast du hier den Donaukanal zu einem Multipolygon mit Lücke gemacht (unter der Schrägseilbrücke bei der Freudenau waren 2 Punkte nicht mehr miteinander verbunden), wodurch er nicht mehr korrekt gerendert werden konnte. Ich habe es ausgebessert: changeset/96940251 aber bitte schau das nächste Mal besser auf die Multipolygone.

If you are mapping such obviously private swimming pools, could you please at least tag them with access=private? Otherwise they will show up on maps supposed to show only public bathing places. (This issue has been previously discussed on several mailing lists.)

Ich schließe mich den anderen beiden Kommentaren an: eine Begegnungszone ist sehr wohl als living_street (mit zusätzlichen Tags) zu taggen. (Danke british für das Umtaggen.) Siehe den Konsens im Forum:
https://forum.openstreetmap.org/viewtopic.php?id=65566

Der Forum-Thread wurde auch auf der Mailingliste verlinkt:
https://lists.openstreetmap.org/pipermail/talk-at/2019-December/010423.html
und es gab dort keine Einwände. (Stattdessen fand die Diskussion weiterhin im Forum statt. Auch die Teilnehmer, die so wie ich eigentlich die Mailingliste bevorzugen, haben sich dem Forum-Thread angeschlossen.)

Demzufolge ist es eindeutiger Konsens der Community, sowohl im Forum als auch auf der Mailingliste, living_street zu benutzen. Die englischsprachigen Straßentypen der OSM kennen leider keine Unterscheidung zwischen Wohnstraße und Begegnungszone, weil es international eher unüblich zu sein scheint, daß beide Konzepte mit subtil unterschiedlichen Regeln in den Gesetzestexten vorkommen, wie es in Österreich der Fall ist. Aber living_street (das auch in anderen Ländern für Begegnungszonen verwendet wird) paßt auf jeden Fall besser als residential (das einfach nur eine ganz normale Straße in einem Wohngebiet ist).

> Aber da renne ich leider gegen die "älterer Tag ist weiter genutzt und muss bleiben"-Wand.

Ich würde dafür die Hauptverantwortung bei den Entwicklern des openstreetmap-carto-Mapnik-Stils suchen. Nachdem dieser Stil der Default-Stil auf openstreetmap.org ist und leider zwar die veralteten Tags rendert, die aktuellen aber nicht, und sich daran seit Jahren auch nichts geändert hat, ist der Widerstand gegen die Entfernung der alten Tags nachvollziehbar.

Das ist halt das Problem in der OSM, daß sich immer wieder die Entwickler einzelner Consumer strikt weigern, Konsensentscheidungen der Mapper auch in ihrer Software bzw. ihren Datenbankabfragen umzusetzen, und de facto keinerlei Möglichkeit besteht, sie dazu zu zwingen. Nicht einmal beim Default-Rendering auf der eigenen Webseite.

OK, das ergibt Sinn.

Das Problem sind dann wohl die Platforms, die nicht als Punkt gemappt sind, sondern als Linie oder Fläche. (Wäre es in jenen Fällen evtl. sinnvoll, extra einen highway=bus_stop Punkt draufzusetzen? Oder macht das das Chaos nur noch schlimmer?)

Ich sehe mit dem "Refined Public Transport"-Proposal übrigens noch ein ganz anderes Problem:
osm.wiki/Talk:Proposed_features/Refined_Public_Transport#Stop_areas

Bzw. "schon länger nicht mehr der Fall" *war*, vor deinen Edits.

Das ist aber nicht mehr gängige Praxis, das wurde fast überall in Wien genau umgekehrt umgetaggt, bzw. gleich von Anfang an mit dem highway=bus_stop auf der stop_position getaggt.

Konkrete Vorschrift, das auf die eine oder andere Art zu machen, scheint es allerdings keine zu geben (die Tag-Definition im Wiki schreibt nur, daß deine Art "am Weitesten verbreitet" ist, wobei das aber zumindest in Wien schon länger nicht mehr der Fall ist), und auch das neueste Proposal:
osm.wiki/Proposed_features/Refined_Public_Transport
würde beide Varianten zulassen.

Beide Varianten haben ihre Vor- und Nachteile, mir geht es vor allem darum, eine Edit-War zu verhindern.

The Café Griensteidl is long gone (closed June 2017, see https://en.wikipedia.org/wiki/Café_Griensteidl ) and its successor Café Klimt also closed several months ago (March 3, 2019, i.e., 11 months before your commit), please do not readd it. I have now tagged the 2 stores that are now in this building.

Außerdem sollten, wenn die Busspur getrennt gemappt ist, auch die Busrelationen über die Busspur geführt werden und nicht über die Hauptfahrbahn, und die Haltepunkte sollten auch auf der Busspur sein und nicht auf der Hauptfahrbahn.

Nein, eine Busspur taggt man keinesfalls als highway=bus_guideway. Das ist nur für Spurbusse gedacht. Siehe osm.wiki/DE:Tag:highway%3Dbus_guideway – "Achtung: nicht bei normalen asphaltierten Busspuren benutzen; die korrekte Kartierung hierfür ist highway=service+access=no+bus=yes" – bzw. highway=bus%20guideway – "Do not use this on normal paved roadways that are designated for buses only.".

Ich persönlich halte das Micromapping einzelner Spuren als getrennter Ways (auch bei Gehsteigen usw.) auch generell für den falschen Weg! Es gibt auch Tags wie osm.wiki/Lanes mit denen man die Information auf den normalen Straßen-Way setzen kann. Eigene Ways machen meiner Meinung nach nur bei klarer baulicher Trennung Sinn. Für Gehsteige gilt z.B., daß die Straße überall überquert werden darf außer unmittelbar (<25m) neben einem Schutzweg (dann muß dieser benützt werden). Das Mapping von Gehsteigen als highway=footway kann das nicht abbilden. Im Falle der Busspuren sehe ich, daß deine Busspuren zwar in die Straße münden, aber nicht von ihr kommen, der Bus müßte sich also hineinteleportieren.

Aber wenn du die Busspur unbedingt getrennt mappen willst, dann bitte als highway=service mit entsprechenden access-Tags, NICHT als highway=bus_guideway. (Und bitte verbinde die Spur auf beiden Seiten mit der Straße, nicht nur auf einer.)

Und wenn in diesem Fall der Radweg auf und nicht neben die Busspur führt, dann sollte das highway=service mit entsprechendem bicycle=yes ausgestattet werden und nicht ein cycleway danebengezeichnet sein.

This restaurant closed permanently back in 2012! There is no restaurant at this address anymore. (You also misspelled "Lieserln", but that is irrelevant because you should not have added this restaurant to begin with.)

Sorry, but this changeset contains 2 major errors:
1. a building in Paris, France (very far from the area you normally edit in!) was corrupted (the rectangle had become a huge pentangle overlapping other buildings) because two nodes were wrongly unified,
2. you changed the node for the town Botlich in Dagestan, Russian Federation from a town to a dentist. If you really intend to map a dentist at that location, please create a new node (and consider filling in additional information such as the name of the dentist) and do not destroy the existing town node.

Since these two changes were the only changes in these changeset and both are clearly wrong, I have reverted your changeset:
changeset/80224754

In the future, please check your edits more carefully before commiting them.

Why would I delete your note from changeset/79439495? It is informative. I don't delete useful notes.

As for the documentation:

* railway=tram_stop:
railway=tram_stop
"It is used on tram tracks (railway=tram) and also on light rail tracks (railway=light_rail) where the halt ressembles more a tram stop than a railway halt (railway=halt)."
Only the tracks matter, not the relations, and in this case, we are actually on tram tracks. In addition, even if the tracks were light_rail tracks (which they are not), railway=tram_stop would still be correct because the stops actually "[resemble] more a tram stop than a railway halt".

* railway=halt:
railway=halt
"For a tram stops on railway=tram and railway=light_rail systems the tag railway=tram_stop should be used."

So I don't see what is not documented.

The NJ River Line was also tagged that way by you, so it is not a valid example. Just because you already made the same mistake elsewhere does not make it any less a mistake. Do you have any examples of that tagging scheme being used for a tram-train hybrid (in the tram section(s)) by other mappers?

IMHO, this tagging is also wrong for the NJ River Line (because it is inconsistent with the global guidelines in the OSM wiki and with the definition of some English-language terms such as "station"), but it is up to the New Jersey (or US in general) community to decide how they want their local features tagged (so please ask them, and next time ask the relevant local community BEFORE doing such a retagging of already mapped features).

Interessanterweise steht im englischen OSM-Wiki line=… auch als Tag für railway-Objekte drinnen:
line=*

Allerdings nicht so, wie es hier verwendet wurde (line=light_rail auf der Relation), sondern als der Name der Bahnlinie auf den railway=… Objekten. Also ist line=light_rail auf jeden Fall undokumentiert, da gebe ich dir recht. Auch:

* osm.wiki/Public_transport#Service_routes
* osm.wiki/Relation:route
* route=train
* osm.wiki/Relation:route_master

kennen kein "line=…".

Was ich meine ist: route=train + line=light_rail ist als light rail identifizierbar und wird auch von der ÖPNVKarte als solches gerendert, route=light_rail (ohne den umstrittenen line=… Tag) ebenfalls. Letzteres (route=light_rail) wird auch in anderen Gegenden verwendet. Nur route=train hingegen wird logischerweise als Zug gerendert, denn hellsehen kann kein Renderer.

Wir werden wohl die Berliner Community fragen müssen. (Über die talk-de Mailingliste?)

Wenn line=light_rail nicht OK ist, sollte es dann nicht route=light_rail statt route=train sein? Oder sollten alle Berliner S-Bahnen nur route=train sein? Derzeit ist auf der ÖPNVKarte die S1 als einzige Berliner S-Bahn gelb (train), alle anderen sind grün (light_rail). Das paßt nicht zusammen.

Ich möchte mich als Wiener da nicht einmischen (ob jetzt train oder light_rail richtig ist), deshalb tagge ich es nicht gleich selbst um, nur konsistent sollte es halt sein. (Die Wiener S-Bahnen sind als normale Züge getaggt, die fahren aber auch auf denselben Gleisen wie die Regionalzüge und teilweise sogar Fernzüge, während Berlin ein eigenes Gleisnetz für die S-Bahnen hat. Daher kann man das nicht wirklich vergleichen. Mir kommt es auf die Konsistenz innerhalb des jeweiligen Netzes an.)

Why are you splitting all those stop areas and creating those stop area groups? I am not convinced that this is an improvement. Since you are not the only one doing this, I have started a thread on the talk-at mailing list: https://lists.openstreetmap.org/pipermail/talk-at/2020-January/010445.html