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.

Hallo Hugo.

Bei der Umleitung hast du die ganzen Relationen kaputt gemacht, wo die ganzen Reihenfolgen durcheinander gebracht worden sind.
Die habe ich (so gut es geht) behoben mit Ausnahme des AirLiners und Busses H (Kesselhutweg => Anne-Frank-Straße), dessen Verlauf am Hauptbahnhof man vor Ort nochmal überprüfen soll.

Liebe Grüße
Manuel

Was ich eigentlich meine ist, dass ich glaube, der zweite Doppelpunkt sowie der Strich vertauscht sind.

Sicher, dass 19:00:20-30 richtig sei?

Das habe ich lediglich beim Vorbeischauen bemerkt, JOSM wirft hier keine Fehler ab (lediglich für "shop=yes", weil es so ungenau ist). Allerdings gibt es in JOSM Vorlagen (u.a. bei den Merkmalen, über den Tags), wo solche probleme verhindert / -mindert werden können.

Hallo,

du hattest für den shop-Key aus Versehen shop=clothing=women angegeben anstelle von shop=clothing und dann clothing=women angegeben. Das habe ich mal korrigiert, beim nächsten mal aber bisschen vorsichtiger sein. ;)

Grüße
Manuel

Sind die neuen Gebäude alle Teile der existierenden Gebäude? Wenn ja, dann sollte hierzu building:parts verwendet werden.

Eigentlich gilt "parking:lane:*" als veraltet und sollte nicht verwendet werden. Was ich eigentlich meinte ist, dass der Syntax zwischen dem alten und neuen Format unterschiedlich ist und das reine Entfernen von ":lane" von "parking:lane:*" meistens nicht ausreicht (die einzige Ausnahme ist, wenn kein Parken existiert, da sind beide Formate gleich).

Eigentlich ist es Street Parking, was hier wichtig ist: osm.wiki/Street_parking

Jedenfalls, was ich meine ist, dass im alten "parking:lanes:*"-Tagging zuerst die Orientierung angegeben wird wie z.B. "parking:lanes:both=parallel" und dann mit der Orientierung die Art des Parkens wie z.B. "parking:lanes:both:parallel=on_street". Beim neuen "parking:*" aber ist "parking:both=parallel" ungültig, ebenso existiert "parking:both:parallel" nicht. Stattdessen verwendet man "parking:both" für den Typ (z.B. "parking:both=on_street") und für die Orientierung dann "parking:both:orientation".

Ja... nicht ganz, da habe ich den gleichen Fehler gemacht, als ich bei Darmstadt, Mainz und Wiesbaden die Parking-Tags erneuert habe.
Die Idee ist, dass bei "parking:lane:*" zuerst die Orientierung und dann die Art des Parkplatzes angegeben wird, bei "parking:*" allerdings zuerst die Art und dann die Orientierung d.h. einfach das ":lane" zu entfernen ist nicht korrekt.

Mehr Details: https://community.openstreetmap.org/t/unusual-and-not-documented-shop-values/106183

Da war ich tatsächlich zu unvorsichtig. Ich habe jedenfalls die ganzen "parking:*"-Tags nochmal überarbeitet, was somit größtenteils behoben sein sollte (abgesehen von den einigen Straßen, wo der Typ nicht gegeben ist).

Das embedded_rails in der Bismarkstraße ist redundant, denn es wurde schon als embedded_rails:lanes eingetragen.

Ich glaube, hierzu sollte ein zweiter Blick geworfen werden, denn in Südrichtung ist der Weg ein gemischter Fuß-/Radweg, in Nordrichtung ist es allerdings ein Fußweg für Fahrrad frei.