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
Nee, habe auch bei einfachen Wanderwegen und route=road Relationen das Problem entdeckt, s.u…
Mmh, da hat iD meine korrekt sortierte Kreis-Variante (roundtrip=yes) komplett umsortiert und den neuen Weg als ersten verwendet ohne ersichtlichen Grund und ohne auf die Stops zu achten: https://www.openstreetmap.org/changeset/100123894
Wer in JOSM mit unvollständigen Daten außerhalb der Download-Area arbeitet sollte sich grundsätzlich Strg+Alt+D vor dem Aufteilen von Linien oder dem Verschieben/Löschen von Punkten angewöhnen.
JOSM hatte da auch seine Problem und hat sie bei mehrfach befahrenen Abschnitten immer noch, allerdings hat sich auch einiges gebessert und bei komplett geladener Relation gibt es einen Validator-Test.
Ja, irgendetwas ist faul und den Eindruck mit genau der falschen Position bei einfachen Beispielen habe ich auch.
Wenn man das Fenster zum Ändern der Busrelation in JOSM offen hat, sollte man es auf jeden Fall vorher mit OK schließen, bevor man an einem Weg oder einer Haltestelle Änderungen vornimmt, sonst kommt es evtl. zu Fehlern.
Ich habe bis heute nicht verstanden, wozu die Reihenfolge gebraucht wird. Welche Anwendung braucht das?
https://waymarkedtrails.org kann daraus Höhenprofile für die Rad-/Wander-/MTB-/…Routen erstellen.
Automatisches Sortieren in der Anwendung ist nur bedingt tauglich, da es nicht immer korrekte Ergebnisse liefert.
Trufi erstellt gerade im Auftrag der Weltbank, zusammen mit lokalen Mappern eine App für den ÖPNV in Nouakchott, Hauptstadt Mauretaniens. Dort gab es bis vor einer Woche nicht eine einzige PT-Relation. Die Daten werden in OSM gemapped, in der Trufi-App genutzt und auch nach GTFS exportiert.
Ähnliches gilt für Cochabamba, CO, Duitama, BO, Managua, NI, …
Liegt das daran, dass die Sortierung es falsch macht, oder daran, dass das Datenmodel es nicht erlaubt? Ich frage, weil es mir bei manchen Relationen einfach nicht klar ist, was die überhaupt darstellen sollen und wie eine korrekte Sortierung aussehen müsste. Wenn das nicht 100% klar ist, dann darf man sich über “kaputte” Relationen nach der Bearbeitung nicht wundern. Der Editor muss ja bei Aktionen, die Wege splitten oder vereinen, berechnen können, wo welche Teile nach der Aktion hingehören.
Manche Routen sind halt komplex, sie widersetzen sich schlichtweg einer Automatisierung.
Sie benutzen einige Wege doppelt - in der selben oder in der anderen Richtung - …
Hier ein Beispiel, das nach einer automatischen Sortierung in der Regel “Inseln” enthält, die jeweils einen “roundtrip” darstellen.
https://ptna.openstreetmap.de/relation.php?id=9949420&lang=de
Das ist eh schon ein Rundkurs. Die Strecken oben links um Hanfeld herum oder unten am Starnberger See tauchen nach einer automatischen Sortierung gerne mal als isolierte Rundkurse auf.
Der Editor sollte nach dem Aufsplitten (was ja eine lokale Aktion auf einem einzelnen Way ist) die lokale Reihenfolge wieder herstellen ohne die gesamte Reihenfolge zu verändern.
Dazu reicht es in der Regel aus die beiden Anschluss-Ways zur lokale Sortierung heranzuziehen.
Schlimmer wird’s natürlich, wenn der Way zwei mal in der Relation vor kommt.
Soweit zur Theorie.
“In der Theorie gibt es keinen Unterschied zwischen Theorie und Praxis, in der Praxis schon!”
Rad-/Wander-/MTB-/ÖPNV-/…-Relationen definieren nicht nur, welche Wege dazu gehören, sondern auch in welcher Reihenfolge sie zu benutzen sind
- nur so komme ich vom Start zum Ziel
- nur so weiß ich was der 1. und was der letzte Way sind, was Start und Ziel überhaupt sind.
Auf einer Karte, die “lediglich” die roten, gelben, … Linien “malt” ist die Reihenfolge völlig uninteressant - auch für den Leser.
Aber abstrahieren wir doch mal vom Begriff “Map” in “OpenStreetMap” und begeben wir uns auf die Datenebene in der DB.
Wenn’s ums Navigieren geht, sieht’s nämlich schon ganz anders aus - da spielt die Reihenfolge der Ways eine Rolle, und die Reihenfolge kann in der Regel nicht automatisch ermittelt werden.
Also bei Relationen mit Schleifen, dann entstehen wahrscheinlich ähnliche Unstimmigkeiten wie bei iD, wenn involvierte ways geschnitten werden, siehe Github Besprechung: https://github.com/openstreetmap/iD/issues/4876
QA und das Auge der Personen beim Editieren profitieren auch stark von richtiger Sortierung.
Bei den ganzen zusammengeführten Issues verliere ich den Überblick und das ursprünglich geschilderte Problem hat nichts mit mehrfach befahrenen Abschnitten zu tun.
Nein, einfache Schleifen sind bei JOSM kein Problem und im Moment finde ich nicht mal auf Anhieb ein Beispiel, wo es bei PTv2 Probleme gibt. Kann es sein, dass es nur noch bei neu angelegten (id=0) Relationen und Wegen ein Problem gibt? Werde wohl meine JOSM-Tickets überprüfen müssen. Bei Wanderwegen sieht es leider anders aus. Wie weit sind mehrfaches Auftreten von Wegen bei PTv1 und sonstigen Route-Relationen vorgesehen und dann wirklich ohne Rolle oder mit jeweils “back-/forward”? Jedenfalls beinhalten einfache Schleifen nicht zwangsläufig mehrfach benutzte Wegstücke und manch Mehrfachbenutzung fällt nicht so schnell als Schleife auf. Ein paar Beispiele zum Testen (erst einmal nur PTv2):
- https://www.openstreetmap.org/relation/2458059
- https://www.openstreetmap.org/relation/12422469 mit noch mehr Beispielen in route_master
- https://www.openstreetmap.org/relation/11242086 mit noch mehr Beispielen in route_master
- https://www.openstreetmap.org/relation/12384346 mit noch mehr Beispielen in route_master