Bei der Prüfung der Buslinien mit https://ptna.openstreetmap.de/results/DE/BW/DE-BW-VVS-Analysis.html#A2.5.7 habe ich festgestellt, dass insbesondere im Raum Backnang zahlreiche Busrelationen etliche Fehler aufweisen. Auch 2 Relationen, die in den Bereich des Kreises Ludwigsburg führen und die ich schon mal überarbeitet hatte, sind davon betroffen. Der Kollege verwendet dafür den iD-Editor, der m.E. für Busrelationen nicht geeignet ist. Ich habe den Kollegen gestern angeschrieben, s.u. https://www.openstreetmap.org/changeset/100558886#map=19/48.94291/9.42478 . Er hat noch nicht geantwortet, macht aber eifrig weiter. Seine Tätigkeit sollte überprüft werden, um den Schaden in Grenzen halten zu können.
Servus ghostrider44,
ein fast unbekanntes Feature bei PTNA: man kann die Linien direkt addressieren: (_ oder )
-
https://ptna.openstreetmap.de/results/DE/BW/DE-BW-VVS-Analysis.html#bus_455
-
https://ptna.openstreetmap.de/results/DE/BW/DE-BW-VVS-Analysis.html#bus_457
-
https://ptna.openstreetmap.de/results/DE/BW/DE-BW-VVS-Analysis.html#11679631
Sorry, dass ich mit der Dokumentation ziemlich hinterher hinke.
Gruß,Toni
Edit: bin mir nicht mehr sicher, ob ‘skyper’ oder jemand anders den Feature-Request gestellt hatte.
Das mit den Busrelationen habe ich selbst auch schon unwissentlich mit iD verursacht. Da reicht ein simples Teilen eines ways mit iD anscheinend aus.
Ich kann das selbst nicht nachvollziehen, da ich mich mit Busrelationen noch nie befasst habe, aber skyper hat mich darauf aufmerksam gemacht.
Bei Wanderrelationen scheint das Teilen eines ways hingegen die Relation in der Sortierreihenfolge zu erhalten.
VG Reiner
Nur um es gesagt zu haben: gehen Metadaten wie Buslinien kaputt, weil jemand die Grunddaten verbessert, kann man über den Begriff “Schaden” zumindest diskutieren.
Der User ändert auch Schlüssel an administrative Grenzen, damit werden die nicht mehr auswertbar. Innerhalb 2 Tagen 2 x. 
History ganz nach rechts scrollen.
Die Buslinien sind aber wohl Hauptziel des Mappers, nicht Kollateralschaden.
Ich kommentiere mal den Änderungssatz mit dem seltsamen Kommentar.
Wenn man einen nicht in sich geschlossenen Weg an einem Node auftrennt, dann macht der iD das m.W. automatisch richtig und ist damit in diesem einen Fall sogar besser als der JOSM.
Aber ansonsten ist der iD für PTv2-Routen ungeeignet. Es wäre schön wenn er sich weigern würde, sie zu editieren. Noch schöner wäre es, wenn der iD akzeptieren würde, dass OSM-Relationen keine mathematischen Relationen sind … das also in der Reihenfolge der Elemente Informationen stecken dürfen, die nicht automatische erzeugbar oder reproduzierbar sind.
Worauf muss ich als ID-User denn achten, bzw. was genau darf man nicht mit ID machen?
Ich nutze seit Jahren JOSM und nur gelegentlich iD, mein Eindruck bzgl. iD mag also “gefärbt” sein.
Ich empfand die Handhabung von Relationen in iD als sehr unübersichtlich und umständlich.Ich kann dem echt nichts abgewinnen.
Rad-/Wander-/ÖPNV-/Road-/…-Relationen sind empfindlich was die Reihenfolge ihrer Elemente (Member) angeht.
Bei größeren Relationen wird das in Id wohl sehr unübersichtlich, welches Element wo steht und wo es eigentlich hingehört.
JOSM hat hier einen eigenen komfortablen Relations-Editor, bei dem man auch automatisch sortieren kann (aber häufig unbedingt manuell machen sollte)
Wie meinst Du das? Wenn die angeschlossenen Member geladen sind, dann macht JOSM das auch richtig.
Ja. Ich meinte, dass iD das m.W. immer richtig macht und man bei JOSM etwas vorbereiten muss, nämlich den Weg und beide Endpunkte anwählen und dann “Eltern laden”. Tut man das nicht vorher, dann macht JOSM zu 50% Quatsch. Ich hab ne dreistellige Zahl solcher Fehler korrigiert und sie stammten nie aus iD und das fand ich gut. Auch wenn ich ansonsten eine eher aggressive Haltung zu iD habe … das muss ich ihm lassen.
Ich benutze auch nur ganz ganz selten iD und meine Meinung kann veraltet sein … verlass Dich nicht darauf.
Einen offenen Weg an einem Node durchschneiden ist mW. kein Problem im iD. Im JOSM sollte man VORHER sowohl den Weg als auch seine beiden Endpunkte anwählen und Alt-Ctrl-D machen (“Eltern laden”).
Das Ändern von Tags ist auch kein Problem.
Das Hinzufügen von Membern ist bei PTv1-Routen, Route-Mastern und Stop_Areas kein Problem. Aber bei PTv2-Routen. (Die Funktion “zur Relation hinzufügen” ohne eine Einfügestelle anzugeben gibt es auch im JOSM und ist da ebenfalls unbrauchbar.) Falls es eine Funktion “automatisch Sortieren” gibt: Finger weg (auch im JOSM).
Bei Nicht-ÖPV-Relationen habe ich verschiedene Meinungen gehört und sag mal lieber nichts.
Inzwischen hat er geantwortet und das Ganze sieht nach konstruktiver Diskussion aus.
Wir haben inzwischen persönliche Nachrichten ausgetauscht. Bei den nicht ganz einfachen Busrelationen habe auch ich schon Fehler begangen. Gemeinsam werden wir es schon in Ordnung bringen.
In den letzte drei Monaten habe ich den Eindruck, dass iD beim Auftrennen von Wegen die Reihenfolge in Routen testet, dann aber falsch herum zusammensetzt.
Wie gesagt, bei mir war es auch so. Simples Auftrennen eines ways (Straße) mit iD hat die daraufliegende Busrelation beschädigt. Was genau beschädigt wurde, kann ich nicht sagen, da ich mich mit Busrelationen noch nie beschäftigt habe, aber ich vermute mal irgendwelche Reihenfolgen.
Siehe hier
https://www.openstreetmap.org/way/50089361 und der dazugehörige Änderungssatz mit Kommentar von Skyper https://www.openstreetmap.org/changeset/99216821
VG Reiner
Des Pudelskern: es ist weniger ein Problem der Editoren, sondern eines Taggingschemas, dass für die Praxis viel zu wenig robust ist.
Ja, es ist zuwenig robust. Für die Fahrwege habe ich eine robustere Lösung ausgearbeitet … es ist also möglich. Aber bei den Haltestellen sehe ich keine praktikable Lösung. (Durchnumerierte Roles haben wir damals ausprobiert und es ist einfach Müll).
Des Pudels Kern liegt aber m.E. woanders:
Seit 2009 dürfen Relationen Informationen in der Reihenfolge der Member haben und wenn ein Editor das einfach nicht unterstützen will, dann ist das schon gegen OSM gerichtet. Man kann ja die Relationen wieder mathematisch (ohne Reihenfolge) machen … aber das ist dann eine Entscheidung von OSM und nicht von einem Editor.
Das Thema ist indirekte Änderungen bei Relationen, dass kommt naturgemäss bei den Haltestellen eher selten vor (Node merge dürfte der einzige relevante Fall sein der potentiell zu Problemen führt), und deshalb ist das weniger problematisch (wobei das Problem bleibt das es keinen algorithmischen Weg gibt die Nodes korrekt anzuordnen).
Was sich 2009, d.h. API 0.5 → 0.6 vor allem geändert hat, ist das eine Relation mehrmals das gleiche Element mehrmals beinhalten darf (0.6 hat sprachlich klargestellt, dass die Reihenfolge der Elemente erhalten bleibt, aber IMHO war das technisch immer so), vorher war das, und ergab auch, ein Fehler.
Die Probleme sind ja die Fälle “Strasse wird zweimal befahren” und “mehrmalig benutzte Kreuzung”, was sich durch eine Nummerierung wohl lösen lässt (die muss nicht einmal global für die ganze Relation sein, sondern nur für die Wege mit mindestens einem gemeinsamen Punkt). Natürlich nur wenn man überhaupt noch Wege in PT Routen haben will.
Die Übersetztung der gesamten Seite fehlt halt noch: https://wiki.openstreetmap.org/wiki/Public_Transport_Network_Analysis/Analysis#Hidden_Links
Beim RVF habe ich es auf der Seite dokumentiert: https://ptna.openstreetmap.de/results/DE/BW/DE-BW-RVF-Analysis.html#A2.1.2
Nee, das kommt nicht von mir. Ich habe nur vorgeschlagen es auch beim GTFS auf routes.php auch anzuwenden. Z.B. https://ptna.openstreetmap.de/gtfs/DE/routes.php?feed=DE-SPNV&release_date=2021-01-19#train_N49