Diskussion über Public Transport Version 3

Zur Klarstellung: Reden wir von Segmenten als zusätzliches Daten-Grundelement (das es bis Oktober 2007 schon mal gab). Oder verstehen wir unter Segmenten (normale) Relationen, die Teilstücke des Fahrweges beschreiben?

Wenn es ein zusätzliches Daten-Grundelement sein soll: Wie wahrscheinlich ist es, dass das eingeführt wird? Gibt es andere Anwendungsfälle, in denen Segmente “vermisst” werden?

Unabhängig davon: Gäbe es Sinn, dass mal “face to face” zu diskutieren, am besten auch mit Vertretern derjenigen, die diese OSM-Datenstruktur nutzen wollen (Fa. Mentz und andere). Zum Beispiel auf dem kommenden FOSSGIS Hacking Event.

Ich kann mir nicht vorstellen, dass die Routen mit solchen Minisegmenten dann noch lesbar und pflegbar sind.

Ich denke, man kann unabhängig von der Anzahl der Relationen dafür sorgen, dass im Normalfall gar keine Arbeit mit den Relationen entsteht. Das hab ich jedenfalls in meinem Vorschlag zu erreichen versucht.

Wenn wir in einer Gesamtrelation auch noch das “‘’/forward/backward” streichen, dann kann man nicht einmal mehr eine Linienkarte mit Pfeilen erstellen. Dann kann man die Routen besser ganz streichen.

Bist Du Dir sicher, dass Du PTv1 wirklich meinst? In PTv1 hat man eine einzige Route für die gesamte Buslinie und jeder Weg kommt da nur einmal vor! Das ist nichts im Vergleich zu PTv2. (Es gibt allerdings viele fehlerhaft gemappte)

Weide

Die meine ich.

Die Verkehrsunternehmen und Mentz DV haben zur Zeit und m.W. auch in Zukunft mit den OSM-Routen nichts vor. Die Mitarbeiter bei Mentz DV editieren Routen nur deshalb, weil sie beim Editieren der Haltestellen angepasst werden müssen.

Weide

Und wer könnte denn mal was mit Routen vorhaben?

Ich bin sehr pragmatisch eingestellt und schätze es, wenn mein Aufwand einem gefühlten Nutzen gegenübersteht. Routen wären für mich gefühlt die Kür. Innerstädtische Haltestellen (also überwiegend Bus- oder Straßenbahnhaltestellen) einheitlich zu mappen und die diversen Schemata abzulösen scheint mir demgegenüber das naheliegende Pflichtprogramm zu sein - und vom Aufwand her schon gigantisch genug.

Moin,

bevor wir Details neuer Datenstrukturen entwerfen, sollten wir überlegen, was das Ziel der Public Transport Daten in OSM ist.
Insbesondere bei den Buslinien liegt vieles im Argen:

  • die Daten sind unvollständig; in manchen Kleinstädten ist keine Buslinie erfasst, weder lokal, noch regional, noch Fernbus
  • die Daten sind als PTv1 oder PTv2 oder in undokumentierten Mischformen erfasst
  • die vorhandenen Daten werden selten gepflegt, es gibt zum Teil Lücken, zum Teil Datenfehler
  • Linien mit vielen Varianten können nicht praktikabel erfasst werden
  • nur wenige Mapper sind bei Buslinien aktiv
  • Straßen mit vielen Buslinien können von vielen Mappern nicht editiert werden ohne die Buslinien kaputt zu machen

Der einzig erkennbare Nutzen ist bislang eine sehr unvollständige und teilweise fehlerhafte Linienkarte.

Ein sinnvolles Fußgänger-ÖPNV Routing würde die vollständigen Fahrplandaten in allen Linienvarianten erfordern.
Das ist mit unseren Mitten nicht möglich, wie schon Osmonav geschrieben hat.
Mittelfristig werden sich ohnehin Onlinedienste zu diesem Zweck durchsetzen, da sich mobile Datenverbindungen verbreiten und
Onlinedienste auch kurzfristige Fahrplanänderungen und teilweise aktuelle Verspätungen berücksichtigen können.

Eine Ausnahme der Betrachtungen zu Fahrplandaten sind Fähren, die zwischen zwei Anlegern pendeln.
Dort sind Fahrzeit, Takt und Betriebszeiten recht leicht zu erfassen und stellen eine Hilfe für das Routing dar.

Die von Weide vorgeschlagene Linienerfassung über Segmente würde es vereinfachen, Straßen zu editieren, da nur eine Relation angepasst werden muss.
Andererseits würde eine weitere Abstraktionsebene (Linie - Variante - Segment - Way) den Einstieg in das Thema erschweren.
Wenn diese Variante zusätzlich zu den bestehenden Schemata eingeführt wird, müssten Mapper und Datennutzer noch mehr Regeln lernen.
Eine Verbesserung würde dieser Vorschlag nur ergeben, wenn er die alten Varianten ersetzt. Aber ist das realistisch?

Mehr aktive Mapper und somit bessere Daten kann man m.E. nur gewinnen, wenn man die Datenstrukturen einfach hält.
Eine Linienerfassung als geordnete Liste der Haltestellen ohne Streckenelemente wäre einfach und für jeden verständlich.
Defekte Relationen wären fast ausgeschlossen. Mapper, die Straßen bearbeiten, müssen sich nicht mehr mit Buslinien beschäftigen.
Eine Linienkarte müsste man dann allerdings mit Hilfe eines Routers erstellen. An wenigen, mehrdeutigen Streckenabschnitten wären Zusatzdaten nötig.

Eine radikale Vereinfachung wäre der Verzicht auf Buslinien in OSM.
Man könnte dann zu jeder Haltestelle die Liniennummern (mit Angabe des Verkehrverbunds) erfassen und dies als Schnittstelle zu anderen Diensten nutzen.
Linienkarte wären dann allerdings nur mit Daten Dritter zu erstellen.

Oder gar nicht mehr. Denn das Routing über OSM netze ist auch nicht ganz trivial.

Ich denke es gibt nicht umsonst Liniennetzpläne. Damit kann man sich wunderbar orientieren. Warum sollten wir in OSM darauf verzichten. Und weil wir die Daten erfassen, können wir noch mehr als einen Liniennetzplan anbieten. Nämlich die Information welche Haltestelle mit welcher ohne Umsteigen verbunden ist.

Das sehe ich als lösbare Aufgabe für die Editoren, vor allem Josm. Wenn ich in der Routenrelation ein Segment anklicke, sollte es möglich sein, die zu dem Segment gehörigen Ways zu highlighten. Im Gegenteil, kleinere Segmente sind wesentlich übersichtlicher. Das einzige Problem liegt in den Schnittstellen der Segmente. Aber auch das ist anhand der Nodes an den Schnittstellen, die in beiden Segmenten gleich vorhanden sein müssen, lösbar.

Dann hast du noch nie in einer Großstadt eine Straße angefasst. Stichwort z.B. bauliche Trennung, Kreisverkehr etc. Wenn du da 20 Relationen anfassen musst (in jeder Relation muss erst einmal die Stelle gesucht werden, an der geändert wird), nur weil du einen Weg auftrennen musstest (auftrennen im Sinne von Gegenverkehr, z.B. wegen Mittelstreifen - aber auch das Gegenteil, Gegenverkehrswege zusammenfassen, weil jede bauliche Trennung fehlt), wirst du schnell den Vorteil einer einzigen Relation kennenlernen.

Ich gehe mal davon aus, du meinst mit der “Linienkarte mit Pfeilen” kein Linienschema, sondern die Landkarte mit eingezeichneten Buslinien. Du selbst hast geschrieben, dass man auf die Unterscheidung Hin/Rückweg verzichten kann, wenn der Bus denselben Weg zweimal benutzt, etwa um von der B xx nach A-Dorf und zurück zu fahren. Eine “Linienkarte ohne Pfeile” ist auf jeden Fall machbar. Ob wir unbedingt eine Karte “mit Pfeilen” aus nur unseren Daten erstellen können wollen, müssen wir überlegen. Möglicherweise könnte die forward/backward/both-Rule ja auch in der Routenrelation an das Member-Segment gesetzt werden. Das Segment zählt die betreffenden ways in der befahrenen Reihenfolge auf, bzw. in der Gegenrichtung, wenn es mit der Role “backward” eingetragen würde. Damit ergibt sich die Richtung, in der der way befahren wird, aus der Reihenfolge im Segment. Zugegeben etwas mehr Aufwand bei der Auswertung, aber viel einfacher für den Mapper. Die Richtung der einzelnen ways spielt dann keine Rolle mehr.

Es ist richtig, dass in PTv1 jeder Weg nur einmal in der Route drin ist. Aber weil die ways für die Fahrtrichtungen teilweise aufgesplittet sind und teilweise nicht, ist es nicht mehr möglich, den Weg zu überblicken, ganz abgesehen von Sonderwegen für einzelne Fahrten. In Segmenten könnte man die JOSM-Sortierfunktion benutzen, danach müssen alle Wege im Segment eine zusammenhängende Kette bilden. Was fehlt, ist die Kontrolle, ob die Śegmente selbst zusammenhängen, s.o. Ich empfehle hier als Beispiele die Buslinien 31 oder 39 in Hamburg. Das ist in PTv1 einfach nur gruselig.

Auf jeden Fall “normale” Relationen, die Teilstücke der Fahrwege aller hier verkehrenden Buslinien beschreiben.

Die Routen werden zumindest in den sich mit ÖPNV befassenden Karten dargestellt. Einzelne Fahrtvarianten darzustellen, wäre eine Aufgabe, die zusätzlich die Daten der Fahrpläne auswerten müsste.

Eine ausschließliche Erfassung der Haltestellen, wie Seawolf sie vorschlägt, wäre zwar denkbar, aber es wäre schade, wenn die bedienten Straßenabschnitte nicht mehr eindeutig darstellbar wären. Sicher haben wir im Moment noch Lücken und kommen mit der Aktualisierung den ständigen Linienänderungen kaum noch nach. Das liegt aber vor allem an den unhandlichen Relationen in PTv1 und PTv2.

Den Vorschlag von Sven Wacker, einmal “face to face” zu diskutieren, halte ich für sehr sinnvoll.

Wolfgang

Ich würde hier aber eine “Vereinfachung” für unbedarfte Mapper vorschlagen:

Eine Haltestelle ist für jeden zu erkennen. Damit der Name, die Linie und der Operator. Wenn man diesen Node neben die Fahrbahn an die richtige Stelle platziert ist auch die Fahrtrichtung ablesbar. Weitere Angaben Bank, Schutz, Papierkorb kann auch einfach erfolgen. Man könnte sogar ein Bild verlinken.

Nun müsste ein “Relationserfahrener” nur noch eine Relation erstellen und die Straßenabschnitte dazwischen einfügen - eventuell über den Fahrplan.

So können einfache Dinge mit Erweiterungen zu nützlichen Sachen werden. (Ich selbst tue mich auch mit den ÖPVN schwer:

  • nimmt mann das alte oder das neue?
  • warum meckert JOSM wenn die Haltestelle neben einem hw liegt?
  • muss ein Bahnsteig in den Fußweg eingebunden, darübergelegt oder nur verbunden werden?

Um Dresden hat mal jemand einige notes zu fehlenden Bushaltestellen oder Linien gesetzt. Ich ändere so etwas nur, wenn ich vor Ort bin, nach meinem Wissen.

Ehm … ohne eure Diskussion stören zu wollen, möchte ich als PT-unbedarfter Mapper hier fragen: liegt es nicht vielleicht auch einfach daran, dass schon PTv1, erst recht PTv2 zumindest auf den ersten Blick recht abschreckend wirken, sodass einfach nicht genug Mapper mitarbeiten? Ich muss gestehen, dass ich bis heute einfach vor der Mühe zurückgeschreckt bin, die das Einarbeiten in PTv* zu erfordern scheint … auch wenn beides auf den 2. Blick wahrscheinlich gar nicht so schlimm und gut durchdacht sein mag.

Segmente mögen eine tolle Idee sein. Aber wenn sie eine weitere Zwischenebene zwischen Straßen und Routen-Relationen schaffen (? so liest sich das jedenfalls bisher für mich Ignoranten), dann wird man ihre Benutzung und v.a. ihren Nutzen sehr gut erklären müssen, damit PT nicht noch abschreckender wird.

Jep; nämlich jedenfalls nicht noch komplexer als PTv2, sonst wird die Pflege der Buslinien etc. auf ewig einer erhabenen Minderheit vorbehalten bleiben. :slight_smile:

Moin,

nichts für ungut, aber der Bearbeitungsaufwand solcher Fälle ist in JOSM unabhängig von der Anzahl der Relationen:

Kreisverkehr:

  1. Trennen aller Wege an neuen Punkten ein Stück vom Kreuzungspunkt entfernt.
  2. Aüflösen der Kreuzung in einzelne Mini-Wegstücke.
  3. Verbinden aller Miniwege zu einem einzigen Wegstück, Anpassen der Länge(Durchmesser) und Erstellen eines Kreises.
  4. Einbau des Kreisverkehrs in die Wege.

Zusammenführen von getrennten Fahrbahnen:

  1. Trennen der getrennten Fahrbahnen jeweils am Ende des oneway (WICHTIG: Nicht am Anfang des oneway!).
  2. Verbinden der getrennten Fahrbahnen zu einem einzigen Wegstück.
  3. Anpassen der Länge/Führung des Wegstücks und der Eigenschaften (oneway etc.).

Hintergrund:
Durch das Verbinden der vormals getrennten Wegstücke zu einem einzigen Wegstück werden alle beteiligten Relationen über dieses Wegstück geführt, die Reihenfolge der Wege bleibt auch erhalten.

Gruß
Georg

Das ist jetzt ein Witz, oder?

Markier den betroffenen Weg bzw. die betroffenen Wege und mach dann die 20 Relationseditoren auf und editier erst danach weiter.

Die Routen in PTv2 haben ebenfalls diese Eigenschaft. Genau diese Eigenschaft sorgt für eine enorme Empfindlichkeit der Strukturen gegen Editiervorgänge an Straßen. Schätzungsweise über 90% der versehentlichen Zerstörungen an PTv2-Routen kommen daher. (Meist mit JOSM und nicht selten von erfahrenen Mappern.) Meine Konsequenz ist, dass das nicht an diesen Mappern liegt sondern an der zu empfindlichen Datenstruktur. Wir sollten uns bei Fahrwegen nicht mehr auf die Reihenfolge von Ways in Relationen stützen. Entsprechend habe ich in meinem Vorschlag die Segmente anders konstruiert. Ohne Bedeutung der Wegreihenfolge im Segment und mit Bedeutung der Segmentreihenfolge in der Route. Damit ist das Ganze völlig unempfindlich gegen die meisten Auftrennvorgänge (die JOSM “p”-Trennungen). Bei den von Dir angesprochenen Längsauftrennungen sind (glaube ich) bei meiner Segmentart alle Fehler automatisch erkennbar und müssten eigentlich sogar meist automatisch zu beseitigen sein (hab ich noch nicht genau geprüft).

Nein, das hab ich nicht geschrieben und auch nicht gemeint. Ich habe geschrieben, dass man beim Verzicht auf Varianten auch auf getrennte Relationen für Hin- und Rückweg verzichten sollte, weil Wegstücke derselben Richtung in einer Variante zum Hinweg und in der anderen zum Rückweg gehören können. Die “forward”/“backward”-Angaben an Wegen haben übrigens nichts damit zu tun, ob der Bus den Weg sowohl auf dem Hinweg als auch auf dem Rückweg benutzt – sie beziehen sich nur auf die Richtung des Weges und nicht auf die Richtung der Tour.

Weide

zu 1:
Bei den Routen: das Neue (Nicht mit dem alten vermischt. Die beiden sind inkompatibel. Schreib von Anfang an das public_transport:version=2 mit rein, das verbesser den Support im JOSM)
Bei den Haltestellen: Die alten sind mit PTv1 und PTv2 kompatibel. Bei Bedarf ergänzt mit neuen Tags. Die alten Haltestellen sind aber immer nur Nodes. Wenn Dir ein Node reicht, dann mach den Namen und ein highway=bus_stop rein - fertig. Vielleicht noch shelter, tactile_paving und bench angeben.

zu 2: Meine Glaskugel meint: Hast Du public_transport=stop_position reingeschrieben? Die ist immer ein Node des Fahrweges – egal wo sie geographisch tatsächlich liegt. Die andere Glaskugel sagt: JOSM meckert gern, wenn man rein alt getaggte Haltestellen in neuen Routen verwendet. Da hat JOSM unrecht: In PTv2 steht:

This proposal does not replace, deprecate or obsolete the already existing and well known tags.
The usage of the proposed tags is recommended but not mandatory.

http://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Public_Transport&oldid=625726

zu 3: Da habe ich unterschiedliche Meinungen gehört. Das Fußgängerrouting sollte jedenfalls funktionieren. Der Streit geht glaube ich darum, ob man für einen kleinen Abstand einen Weg braucht oder nicht. Vielleicht können die Routingexperten was dazu sagen…

Weide

Aus dem Grund war ich bis vor ein paar Monaten auch gegen Segmente. Aber wenn man damit die Strukturen unempfindlich gegen Editierarbeiten an den Straßen bekommt und deutlich bessere Unterstützung im Editor bekommt, dann lohnt sich das Ganze m.E. Was man mit den von mir vorgeschlagenen zwei Segmentarten allerdings nicht bekommt ist eine Garantie, dass es pro Straße nur ein Segment gibt. Viel weniger: ja; eine: nein.

Weide

Ich hab in meinem Vorschlag nichts zu den Haltestellen vorgeschlagen. Das ist ne ganze Menge! :slight_smile:

Es besagt nämlich, dass das Haltestellenmapping sich nach den örtlich vorhandenen Sachen richten soll und nicht nach dem Bedarf der “Routenheinis”. Jedes neues ÖPNV-Schema sollte m.E. so konstruiert werden, dass das vor-Ort-Mapping ohne Routenkenntnisse möglich ist.

Beispiel aus PTv2 für das, was ein Schema nicht vom Haltestellenmapping verlangen sollte:
PTv2 kann nur eine Platform pro Halt. Sobald jemand am Bahnhof Voerde/Ndrrh. die Brücke in der Mitte des Bahnsteigs mappt haben wir da drei Bahnsteige und nur einer kann in die Route. Das ändert das Fußgängerrouting für Umsteiger.

Weide

Moin!

Das Verfahren ist gut, aber es setzt voraus, dass man

  • josm benutzt
  • diese Technik beherrscht
  • alle Relationen als PTv2 vorliegen
    Bei PTv1 kann josm Rollen wie “backward” und “forward:alternate:2” nicht sinnvoll zusammenfügen.
    Die übrigen 99% der Mapper haben größere Probleme.

Beim Trennen von Fahrbahnen gibt es ohnehin keinen schnellen Weg.

Deshalb behindern ÖPNV-Relationen immer auch die Mapper, die sich dafür nicht interessieren.

Es stimmt schon, dass einem der Relationseditor von JOSM viel Arbeit beim Auftrennen und Zusammenfügen von ways abnimmt.
Das stimmt aber leider nicht mehr, wenn in allen Routen ein Straßenstück durch ein anderes ersetzt werden muss, z.B. bei anderer Straßenführung. Da muss ich jede Relation einzeln anfassen und da kommt in den Innenstädten leicht ein Dutzend zusammen.

Es gibt übrigens seit 2011 ein Proposal Route_Segments für Segmente von Relationen.

Problem damals wie wohl auch heute noch ist aber, dass viele (auch QS-)Werkzeuge mit geschachtelten Relationen nicht zurecht kommen.
Für nicht Informatik-affine Mapper (one information at one place) mag dasselbe gelten.

Das Proposal ist in etwa das was ich mir unter Segmenten für Relationen vorstelle.

Ein Segment, bestehend aus ways, sollte in jede Relation eingefügt werden können. Also z.B. eine bestimmte Strecke von A nach B, in eine Buslinien-Relation, in eine Relation für Bundes-, Land- oder Kreisstraße oder in eine beliebige andere Route (z.B. Deutscher Schnapsdrosselweg).

Für das PTv2 oder PTv3 Thema könnte dann ja nach gleicher Schema ein Bus-Stop und Platform Segment erstellt werden und dies ebenfalls an entsprechender Stelle in die Relation eingefügt werden.

Das Argument ein Vorschlag nicht weiter zu verfolgen, nur weil die aktuellen Werkzeuge dies nicht können kann kein Argument sein.

JOSM konnte am Anfang bestimmt auch noch kein PTv2.

Es muss doch erst mal einen abgestimmten und akzeptierten Vorschlag geben. Dann können die Werkzeuge angepasst werden. Und dann kann es los gehen.
Eigentlich die gleiche Vorgehensweise wie bei jedem IT-Projekt.

Gruß
Gino

Also wenn du so weit gehst, dass Segmente wieder so klein werden, dass sie in beliebige Routen eingefügt werden können, dann kann man auch gleich die Punkte in die Relation aufnehmen. Denn Wege, sind nur Relationen aus Punkten.

Ich lese in dem Proposals nur die “Erlaubnis”, Routen-Relationen in Routen-Relationen zu schachteln. Das einzelne “Segment” wäre ebenso störanfällig wie jede andere Relation - weil das Segment nichts anderes als eine Relation ist.

Wenn Du mit “Relation” “PTv2-Routenrelation” meinst bin ich einverstanden.

Wir könnten aber Segmente definieren, die nicht störanfällig sind:

1.: keine Selbstberührung oder Selbstkreuzung
2.: Anfangs- und Endpunkt werden als Element mit aufgenommen (“from”, “to”)
3.: Löcher dürfen nicht im Segment sein.
4.: Die Reihenfolge der aufgezählten Haltestellen ist die aus der Realität.
5.: Die Reihenfolge der Wege hat dagegen keine Bedeutung. D.h. man kann sie automatisch sortieren (Es geht nur auf eine Art und es geht immer)
6.: unzerschnittene Kreisverkehre bekommen besondere Rollen
7.: Fahrwege und Halte kommen nur in Segmenten vor. Routen enthalten also nur Segmente (in der richtigen Reihenfolge).

Für die noch nicht erfassten Teilstrecken werden besondere Fehl-Segmente eingerichtet. Sie sind genauso, enthalten aber gar keine Wege. Stehen sie am Anfang/Ende einer Route, dann darf auch das “from” bzw. das “to” fehlen (wenn es unbekannt ist).

Damit sind die Dinger nicht mehr störanfällig und ein Editor hat genug in der Hand um fast jeden der heute üblichen Fehler zu finden und die meisten automatisch zu beseitigen.

Weide