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.
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.
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):
Letzteres. (Und es ist genau die richtige Frage um das Problem klar zu machen!)
Es gibt Relationen bei denen eine andere Reihenfolge der Member nichts an der Bedeutung ändert … z.B. eine normale Abbiegerelation mit drei Elementen “from”, “via” und “to”. Die kann man automatisch sortieren.
Es gibt Relationen wie PTv2-Routen von denen jede eine Variante einer Richtung einer Buslinie angibt. In denen bedeutet die Reihenfolge der Haltestellen, dass diese in dieser Reihenfolge angefahren werden. Die Reihenfolge der Wege bedeutet, dass diese in dieser Reihenfolge benutzt werden. Daraus ergibt sich dann die Richtung in der die Wege benutzt werden und das ist wichtig für die Kartendarstellung. Es gibt aber auch unvollständige Buslinienvarianten und das ist völlig legitim. Automatische Sortierung ist da völlig unmöglich. Beispiel:
Nehmen wir mal 5 Punkte A, B, C, D, E von Süd nach Nord auf einer Hauptstraße. Die Wegstücke dazwischen nenne ich mal AB, BC, CD, DE. Jetzt fährt ein Bus wie folgt:
1.: A nach B (Weg AB nordwärts)
2.: B nach D durch das Dorf X (Wege noch nicht erfasst)
3.: D nach C (Weg CD südwärts)
4.: C nach B (Weg BC südwärts)
5.: B nach D durch das Dorf Y (Wege noch nicht erfasst)
6.: D nach E (Weg DE nordwärts)
Der Mapper gibt die korrekte Reihenfolge der Wege mit AB, CD, BC, DE an. Jede automatische Sortierung macht daraus die falsche Angabe AB, BC, CD, DE und die Auswertung ergibt dann fälschlicherweise, dass der Bus zwischen B und D nordwärts fährt während die Angabe des Mappers korrekt angibt, dass der Bus dort südwärts fährt. Diese Route sieht total sortierbar aus und ist es nicht … das Datenmodell von PTv2-Routen erlaubt ganz einfach keine automatische Sortierung.
Das Beispiel ist zugegebenermaßen extrem und sieht konstruiert aus … aber ich habe ziemlich genau das selbst vor Jahrzehnten in Schweden bei Kalmar Länstrafiken erlebt.
Ich denke, https://josm.openstreetmap.de/ticket/19217#comment:3 ist immer noch wahr. Ich habe damals versucht, den Code zu korrigieren, bin aber eben daran gescheitert, dass ich nicht verstehe, was wirklich passieren sollte. Mein Fazit damals: Wenn Leute so komplizierte Konstrukte zusammenbauen, dann sollen sie sich nicht wundern, wenn die regelmässig kaputt sind.
Oder anders rum: Es gibt in der Realität Zusammenhänge, die sich mit den OSM Datenstrukturen nur schlecht oder gar nicht darstellen lassen. Schleifen in Routen gehören dazu. Mein Ansatz wäre es, die Route in eindeutige Teile aufzuteilen oder eben einfach nicht zu erfassen.
In diesem Fall werden durch die Änderung am Weg indirekt und ohne das der Mapper es weiss, Relationen in dem der Weg Mitglied ist geändert.
Dazu muss der neu ersteller Weg am richtigen Ort in allen beteiligten Relationen einfügt wird. D.h. über alle Relationen iterieren in den der Weg Mitglied war und dann jeweils über alle Mitgliedeinträge (role, element) iterieren und bestimmen ob der neue Weg vor oder nach dem bestehenden Mitglied eingefügt werden muss (oder gar nicht, im Fall von turn restrictions und ähnlichen Relationen *). Dies sollte eigentlich jeder Editor beherrschen, braucht auch keine zusätzlichen Informationen. Die Relation muss auch nicht sortiert werden.
Relation sortieren
Dies sollte nur dann relevant sein wenn man direkt die Relation bearbeitet. Grundsätzlich finde ich sollte die Funktion vorhanden sein, aber bei problematischen Relationen eine Warnung anzeigen, dass man möglicherweise Information verliert.
Simon
eins der echten Probleme ist, dass bei Konstrukten die unbekannte Semantik haben (z.B. weil das jemand gerade erfunden hat), man immer möglicherweise was falsch macht.
Der oben beschriebene Fehler bei Wegaufspaltung betrifft den Fall, das der Anwender lieber mit unvollständigen Daten arbeitet und JOSM zunächst mal rausfinden muss, ob mit den vorhandenen Daten alles klar ist oder nicht und dabei dann mit Sonderfällen nicht zurechtkommt.
Keine Ahnung, ob das Problem in anderen Editoren überhaupt auftaucht. Der normale Benutzer lädt ja immer den Breich um den Weg, den er trennen will, dann gibt es - hoffentlich - kein Probllem.
Das Problem ist ja das man ohne mindestens einer der Nachbarwege in der Relation nicht feststellen kann ob das neu erstellte Wegstück vor oder nach dem existierenden eingefügt werden muss (da die Wegrichtung selber in Routenrelationen keine Bedeutung hat).
Das kann ausserhalb eines vollständig heruntergeladenes Gebietes im Prinzip in jedem Editor vorkommen, auch in iD wenn ein Weg über das sichtbare Gebiet (und nicht schon heruntergeladen) herausragt. Aber IMHO sind das Grenzfälle die nicht so häufig vorkommen sollten, dass sie als Erklärung für die geschilderten Probleme taugen.
Bei JOSM sind es beim Aufteilen von Wegen zwei Hürden:
Die Relationen erst einmal laden.
Die benachbarten Wege laden.
Andere Editor Software braucht auch diese Information, nur sollte bei iD zumindest die Relation schon geladen sein.
Es gibt PTv2-Beispiele bei denen Autosortierung schier unmöglich ist, bei diesem einfachen Beispiel bin ich mir nicht sicher. Da ist es eher eine Frage auf was alles geachtet wird. Wenn die Stops in richtiger Reihenfolge und neben der Straße eingetragen sind und auch auf Tags wie oneway=* oder gar Abbiegeeinschränkungen geachtet wird, sollte es fast immer klappen.
Ja.
Was PTv1 angeht gebe ich Dir vollkommen Recht, allerdings wird es noch ewig dauern bis alles auf PTv2 umgestellt wird und für das teilweise Erfassen von Linien ist PTv2 nicht geeignet. Da braucht es schon einiges an Information.
Bei anderen Routen wie foot, bicycle oder road sollte es aber nicht so kompliziert sein. Da fehlen zum Teil ein/zwei definierte Rollen. Leider scheint https://josm.openstreetmap.de/ticket/19633 bei mir am Anfang der Liste immer noch nicht zu funktionieren, was dann auch https://josm.openstreetmap.de/ticket/6166 beeinflusst. Dachte ich hätte das schon gemeldet.
Generell sollte vielleicht eine andere Nachricht erscheinen, wenn JOSM auf einen unbekannten Relationstyp stößt.
Wir weichen vom Thema ab.
In josm haben wir eigentlich kein Problem.
In iD-Bearbeitungen fallen vermehrt Fehler auf.
Im iD-Editor werden beim Splitten von Wegen die neuen Wegstücke offensichtlich falsch herum eingesetzt.
Im iD-Editor wird vermutlich jede angefasste Relation neu durchgerechnet. Es lassen sich aber nicht alle Relationen automatisch berechnen.
Als Beispiel Bus711 http://www.roeltgen.com/gpx/ibro_ol4ptunnel.html?idt=4731670 mit zwei Schlaufenenden. Man kann nur aus Kenntnis der Straßenseite der Haltestellen oder der Haltestellen-Reihenfolge den Fahrweg zusammenstellen.
doch… da muss man beim Wegteilen die anschliessenden Wege laden sonst kann es in die Hose gehen… ID hab ich in Errinnerung nur teilt wenn diese Wege geladen sind…
Aber immer auf ID schimpfen… PTv2 ist eh “kacke” in der jetzigen Form… viel zu viel arbeit bei kaum nutzen… und vieles veraltet, unvollständig oder kaputt
Seit einigen Monaten erscheint in JOSM beim Teilen eines Weges, der z.B. zu einer Route-Relation gehört, ein neues Fenster, das fragt, ob einige zusätzliche Mitglieder der Relation heruntergeladen werden sollen. Bejaht man diese Frage (und beantwortet man auch die nächste, ob diese Entscheidung weiterhin angewendet werden soll), werden die beiden an diesen Weg auf beiden Seiten angrenzenden Relationsmitglieder geladen, um die Position zu bestimmen, wo in der Relation das neue Wegstück eingefügt werden soll.
