OpenStreetMap Forum

The Free Wiki World Map

You are not logged in.

#1 2017-12-17 21:22:32

slhh
Member
Registered: 2012-09-02
Posts: 354

PTv3: Routen, Segmente und Varianten

slhh wrote:

Im Sinne der Ziele gemäß PTv3: Zielsetzung eines modifizierten ÖPNV Modells möchte ich hier Veränderungen im Themenbereich Routen, Segmente und Varianten zur Diskussion stellen.
Diskussionen die speziell die Stop und Platform Member betreffen, sollten jedoch im Parallelthread PTv3: Stopposition und Platform erfolgen.

Hier eine Themenübersicht, die später eventuell noch zu ergänzen ist:

  • Sortierung der Fahrwegelemente

  • Segmentierung von Routen

  • Trennung von Haltestellenauflistung und Fahrwegroute

  • Variantenbildung

  • Belastung der Wege durch Routenmitgliedschaften

  • Routeneditor

Offline

#2 2017-12-17 22:56:46

slhh
Member
Registered: 2012-09-02
Posts: 354

Re: PTv3: Routen, Segmente und Varianten

Weide (im Parallelthread) wrote:
slhh wrote:

Ohne eine gewisse Segmentierung können wir uns auch nicht von der Notwendigkeit befreien, die Wege innerhalb der Route manuell zu sortieren.

Ja, ich halte es auch für extrem wichtig, die Sortierung rauszuwerfen. Sie machen sogar den nicht mit ÖPNV beschäftigten Mappern zuviele Probleme.

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

Nachdem ich längere Zeit mit Segmentrelationen experimentiert hatte und nach Umstellung ganzer Gegenden nicht sehr zufrieden war,

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.

...bin ich zu folgender Alternative gekommen:

An den Anfang, ans Ende und ggf. zwischen die Wege werden Markierungen (Nodes an Way-Enden mit der Rolle "mark") gelegt. Zwischen zwei Marks ist entweder nichts (d.h. eine unbekannte Strecke) oder eine auf nur eine Art verkettbare Menge von Ways ohne Berührungen oder Überschneidungen. Die Ways müssen also zwischen den Marks nicht mehr sortiert sein. Die Forderungen sorgen dafür, dass praktisch alle üblichen Editierprobleme automatisch erkennbar sind.

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.

Offline

#3 2017-12-18 21:37:10

hsimpson
Member
Registered: 2015-07-21
Posts: 667

Re: PTv3: Routen, Segmente und Varianten

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.

Viele Grüße


Fragen zu PTv2? Vlt mal in diese Übersicht schauen?

Offline

#4 2017-12-18 21:57:20

hsimpson
Member
Registered: 2015-07-21
Posts: 667

Re: PTv3: Routen, Segmente und Varianten

slhh wrote:
Weide (im Parallelthread) wrote:
slhh wrote:

Ohne eine gewisse Segmentierung können wir uns auch nicht von der Notwendigkeit befreien, die Wege innerhalb der Route manuell zu sortieren.

Ja, ich halte es auch für extrem wichtig, die Sortierung rauszuwerfen. Sie machen sogar den nicht mit ÖPNV beschäftigten Mappern zuviele Probleme.

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

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.

Viele Grüße


Fragen zu PTv2? Vlt mal in diese Übersicht schauen?

Offline

#5 2017-12-19 01:11:25

slhh
Member
Registered: 2012-09-02
Posts: 354

Re: PTv3: Routen, Segmente und Varianten

@hsimpson

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.

Offline

Board footer

Powered by FluxBB