Da stimme ich voll zu. Hinzu kommt noch, dass ein komfortables graphisches Editieren kaum möglich sein dürfte, solange man manuell sortieren muss.
Für iD gibt es den Vorschlag eines Routeneditors, der aber mit PTv2 nicht funktionieren kann: https://github.com/openstreetmap/iD/issues/1575
Ich hoffe dass deine Schwierigkeiten daran lagen, dass das Konzept noch nicht ausgereift war, oder an behebaren Einschränkungen des Editors. Ein funktionierendes Segmentkonzept ist keineswegs trivial, aber attraktiv genug, um danach intensiv zu suchen. Du kannst ja mal hier detailiert erläutern, wo die Probleme lagen, damit wir daraus lernen können.
Dein Ansatz war mir bekannt. Das ist letztlich auch eine Art von Segmentierung allerdings mit dem Nachteil, dass sie nicht zur Reduktion der Variantenrouten beitragen kann.
Es scheinen mir aber einige gute Ideen enthalten zu sein, die wir vielleicht in modifizierter Form anwenden könnten. So halte ich den mark Member am Anfang und End für sinnvoll, würde aber eine from bzw to Rolle dafür verwenden. Auch das die Lücken erfasst werden, halte ich für sinnvoll, würde dafür aber einen Way vorschlagen, der zum Beispiel als highway=route_gap oder railway=route_gap getaggt wird. Solche Wege könnten auch bei der Editierung der Basisinfrastuktur bei Bedarf automatisch erzeugt werden, um den Benutzer auf ein entstandenes Problem aufmerksam zu machen.
Ich hätte einen Vorschlag für Routenvarianten zu machen:
Man bündelt nur die einzelnen Linienvarianten, entwender, indem man eigene Relationen schafft, oder, indem man besondere Rollen gibt, z.B. v_1; v_2; etc.
Diese Bündel werden nach dem eigentlichen (Haupt-)Fahweg der Linienrelation hinzugefügt.
Das ganze Funktioniert dann, wenn der erste Punkt des ersten Ways der Variante teil des Ursprünglichen Linienwegs ist, ab dem Punkt würde diese Variante also den eigentlichen Linienweg verlassen. Entsprechend müsste der letzte Punkt des letzen Ways der Variante wieder ein Teilstück des Ursprünglichen Linienwegs sein.
Ist ersteres oder letzteres nicht der Fall, muss das dann als alternativer Start oder Ziel interpretiert werden.
Ich persönlich würde die Erfassung in einer eigenen Relation bevorzugen, das hat nämlich den Vorteil, dass man dieser Relation ein eigenes *via=-Tag (und auch *from=, bzw. *to=**, wenn erforderlich) geben kann.
Ein Nachteil wäre, dass man nicht mehr deutlich machen kann, dass z.B. Kurse, die Variante A fahren, nicht mehr Variante B nehmen, es könnten also in den Daten Verbindungen stehen, die in der Realität nicht vorkommen. Dieses Problem gab es jedoch auch schon bei PTv1, weswegen ich das als vernachlässigbar ansehe.
Die Idee ist mir grade eben gekommen, daher sie noch recht rudimentär. Vor allem sollte überlegt werden, ob man auf diese Weise wirklich eine Eindeutige Datenlage schaffen kann, und wenn nein, wie man diese Probleme lösen kann. Aber ich denke es würde sich lohnen, das mal weiter durch zu denken.
Wenn es eine zufriedenstellende Möglichkeit gibt, die Sortierung abzuschaffen, bin ich voll bei euch, dass das ein großer Fortschritt wäre. Allerdings bin ich der Umsetzung desselben gegenüber sehr skeptisch:
Sortierung schafft Eindeutlichkeit: Bei komplexen Linienführungen kann es passieren, dass unsortierte Relationen nicht mehr ohne weiteres einen eindeutigen Linienweg beschreiben. Insbesondere stellt sich die Frage, was passiert, wenn ein Way doppelt im Fahweg vorhanden ist, muss der dann immer noch doppelt in die Relation? Auch könnte es zu false-negative-Meldungen kommen, dass kein geschlossener Linienweg erkannt werden kann, da dieser eine Schleife beinhaltet, die das Programm nicht erkannt hat.
Das Problem wird noch gravierender, wenn man die Erfassung von Linienvarianten in selbstständigen Routenrelationen abschaffen will (was ich ebenfalls begrüßen würde).
Sortierung schafft Übersichtlichkeit: Ich bin derzeit ohne große Hilfsmittel in der Lage, einen Linienweg grob zu validieren, nämlich indem ich bei JOSM prüfe, ob es Lücken zwischen den einzelnen Ways gibt. Das wiederum ist ein sehr guter erster Anhaltspunkt, wenn man die Qualität einer Linienrelation prüfen will. Das gilt übrigens auch für automatische Prüfungen, die derzeit nur checken müssen, ob der erste Punkt eines Ways der Relation auch der letzte Punkt des vorhergehenden Ways ist. Das ist vergleichsweise einfach zu programmieren und kann daher auch ohne Probleme dezentral gemacht werden, was wiederum einen enormen Vorteil darstellt.
Ja, PTv2 braucht die Sortierung bei einigen Routen, um Eindeutigkeit zu erreichen. Das heißt, in der manuellen Sortierung steckt potentiell Information. Somit darf der Editor nicht einfach automatisch umsortieren, da dies die Information vernichten könnte.
Der hier diskutierte Ansatz, um die Erfordernis der manuellen Sortierung für PTv3 aufgeben zu können, ist eine Aufteilung jener Routen in Segmente, die ohne Sortierung nicht eindeutig sind. Die Segmentierung muss dabei so erfolgen, dass jedes Segment ohne Sortierung eindeutig ist, also z.B. keine Schleifen enthält.
Natürlich schafft Sortierung Übersichtlichkeit und wir wollen das sortieren auch nicht verbieten. Allerdings kann und sollte der Editor diese Sortierung innerhalb des Segments oder einer unsegmentierten Route automatisch vornehmen. Dies ist bedenkenlos möglich, da die Sortierung keine Information mehr enthalten würde und somit keine Information vernichtet werden kann.