Hallo.

Deine Änderungen haben dafür gesorgt, dass viele Routen unterbrochen worden sind und repariert werden müssen.
Tatsächlich bin ich der Meinung, dass das ganze Micromapping mit den Bürgernsteigen (bzw. das strikte aufteilen in "hat Bürgersteig" und "hat keinen Bürgersteig") eher übertrieben ist und die ganzen Fragmentierungen OSM eher schadet (u.a. wegen den Routen) anstelle wirklich hilft.

Da wäre ich vorsichtig, da z.B. StreetComplete nach Addressen fragt eines Wohngebäudes fragt und wenn zwei angebliche "Gebäude" die gleiche Hausnummer haben, handelt es sich ganz sicher, dass eines davon ein Gebäudeteil ist.

Eine Lösung ist, einen Umriss über die beiden Gebäude zu zeichnen und davon die Informationen beider Gebäude ins Umriss zu übernehmen (bei Konflikten wie Etagen wird das höhere Gebäude genommen, andere wie Dachmuster werden nicht genommen). Je nach Lage (d.h. wie weit sich die beiden Gebäudeteile sich unterscheiden) werden die alten Gebäude entweder gelöscht oder als "building:part=yes" gemappt (ich habe letzteres genommen, weil man einen Höhenunterschied an den Luftbildern erkennen kann).

Ich verstehe zwar deine Intentionen, allerdings ist der primäre Tag für Namen immer noch "name=*" und sollte auch im multilingualen Kontext beibehalten werden:
osm.wiki/Multilingual_names

Wenn das alles verkehrsberuhigte Straßen sind, müssen nicht die ganzen "maxspeed:type=DE:living_street"-Straßen alle in "highway=living_street" umgeändert werden?

So behoben.

Da war ich tatsächlich zu unvorsichtig und weiß selber nicht, wie das geschsehen ist. Ich habe speziell alle Bus- und Bahnsteige genommen, die "RMV", "RNN" oder "MVG" im Netzwerk haben sowie alle Halte, die nicht "Mainzer Verkehrsverbünde" als Betreiber haben, wobei ich zuerst speziell nach Kriterien filterte und erst am Ende die Halte ohne Netzwerk bearbeite (und natürlich diese auch händisch außwählen).
Tatsächlich habe ich den Fernbus-Halt am Hauptbahnhof sowie KD Mainz acht gegeben (Natürlich habe ich auch noch die drei ORN-Halte am Hauptbahnhof bearbeitet, wobei diese als RNN-Bussteige im RMV-Gebiet etwas schwieriger zu beurteilen sind).

Da man die Gebäude auf den gängingen Luftbildern noch sehen kann, habe ich diese als demolished:* wieder hergestellt.

Hello.

It turns out that you have quite a big changeset which spans through almost the entirety of Eurasia with changes in Korea, Russia and the UK.

Keep the changes to a more local scale and upload more global over multiple changesets.

Greetings
Manuel

I've connected the path with the building but it's otherwise correct.

I noticed that one of paths goes through a building which is a source of conflicts. Is this a building passage or something? Because I doubt that 97a is on a different layer from the footpath.

Hello.

Your changeset is mostly focused in Czechia, though it also changes a node in the UK which results in the unnecessarily large changeset region.

Just for context, this is caused by major construction work where accurate tracking is difficult and may not be without errors. Once February hits and it's finished, all of the MWB and S6 would be cleaned up by the locals anyway and wouldn't touch the line in the meantime.

m.M.n. ist hier eher das Problem, das die Multipolygon-Linien (d.h. die Linien, die das Multipolygon ausmachen) selber die "boundary=postal_code" behinhalten, was aber offiziell falsch ist, da dies nur für Flächen (u.a. das Multipolygon) aber nicht für Linien definiert ist und es für die Linien an sich zu verwenden, ist ein Missbrauch davon.

Hallo LWillms,

eigentlich werden Stationen nicht auf den Gleisen platziert, dass wird nur für die eigentlichen Haltepositionen gemacht. Bahnhöfe und HaltePUNKTE (nicht zu verwechseln mit den eben genannten HaltePOSITIONEN) werden stattdessen mittig der Station platziert.

Grüße
Manuel

Ich habe übrigens die Brücke wiederhergestellt, natürlich mit dem demolished-Präfix. ;)

changeset/146236239

Hallo Michael,

danke dass du bei OSM beiträgst.

Allerdings gibt es für OSM definierte Tags, die man bevorzugt nutzen soll.
Das heißt, die Öffnungszeiten gehören in den Tag "opening_hours", the Telefonnummer in "phone" and dein Betrieb würde ich am besten als "office" bezeichnen (kann notfalls als "office=yes" getaggt werden.

osm.wiki/DE:Key:opening_hours
phone=*
osm.wiki/DE:Key:office

"description", "name" und "webseite" sind hierbei OK, für "note" würde dann nur "Kein Ladengeschäft." ausreichen.

Außerdem gehören Büros zum angehörigen Gebäude und nicht auf irgendwelchen Wegen.

Grüße
Manuel

Hello.

This sounds like a bollard. You can either chose them in iD by specifically searching for it or modify the point where it's located with a "barrier=bollard".

Die Daten sind definitiv eingepflegt, es dauert aber eine Weile, bis die anderen Karten aktualisiert werden. Nach einen Tag sollten die Änderungen allerdings kommen (ggf. mit Strg+F5 aktualisieren).

Hallo.

Beim Anpassen der Kreuzung Flakweg-Frankfurter Straße hast du anscheinend die Relation der Buslinie 820 (Regionalpark => Flörsheim) kaputt gemacht; es gibt eine Lücke in der Route am Anfang der Relation (gut an der Verkehrskarte erkennbar).

Beim Edit hast du anscheinend einen Teil der Pfälsischen Maximiliansbahn als "disused:railway=rail" gemappt, was m.M.n. so nicht korrekt ist, nicht nur weil der Syntax nicht Standard ist, sondern auch, dass die benutzten Gleise dann zu den anscheindend "unbenutzten" Gleisen führen und auch die Linien, die darauf fahren, wurden nicht aktualisiert (sehe die Stelle im OSM Inspector nach).

Ich habe hierzu einen in einen Hinweis erstellt, wo ich mich darüber gewundert habe (und m.M.n. dort weitergeführt werden soll):
note/4034787

Die Idee ist, dass Relationen in OSM sich nicht nur um Datengruppen handeln sondern eine Listen von Daten sind d.h. es gibt innerhalb der Relationen eine Reihenfolge von Elementen.
Karten wie die ÖPNVKarte nutzen hierbei die Reihenfolge der Elemente in den Listen, um den exakten Fahrtverlauf (z.B. Richtungspfeile) zu berechnen, welche ansonsten falsch dargestellt werden.

Allerdings muss man auch sagen, dass iD wirklich nicht für Routen gedacht ist. Als ich beim letzten mal eine Route in iD hinzugefügt habe (Bus 69 in Mainz über Nackenheim), so habe ich zwar einerseits die Reihenfolge für die Gegenrichtung sowie einigen Straßen nicht beachtet, vielmehr aber ist es viel schwieriger, diese Liste dann dort zu korrigieren, da man die Elemente einzeln manuell verschieben muss und nicht immer ist die gewünschte Relation sichtbar.
Ich empfehle dir Routen mit JOSM zu bearbeiten, da dessen Relationseditor viel mächtiger ist (z.B. großflächiges Verschieben der Mitglieder, Verdrehen der Relationsmitglieder) und sogar anzeigt, ob der Verlauf tatsächlich durchgehend ist oder nicht.