Diskussion über Public Transport Version 3

Das kann ich zumindest für den Berliner Raum bestätigen. Lediglich das Auskuntssystem der DB AG nutzt eine eigene Karte. Die Auskunftssysteme der BVG, der S-Bahn Berlin GmbH (Tochter der DB AG) und des Verkehrsverbundes VBB nutzen für das Fußgängerrouting die Mapnik-Karte, bei den Standpunkten der jeweiligen Bahnhöfe und Haltestellen nutzen sie jedoch nicht die OSM-Daten.
Das ist für mich aber kein Grund, das Tagging nicht so zu verbssern, dass das Fußgängerrouting verbessert wird, wenn diese Auskunftssysteme irgendwann in der Zukunft vielleicht die vorhandenen OSM-Daten nutzen. Zumal die Wahrscheinlichkeit, dass sie sich zu diesem Schritt entscheiden, meiner Meinung nach entscheidend erhöht wird, wenn sie sehen, dass die OSM-Daten viel präziser auswertbar sind, als ihre eigene Datenbank.

Zu Ginos Vorschlag in # 4: Finde ich gut. Allerdings faällt mir auch gleich ein Detail ein, an dem man noch feilen müsste: Wie kennzeichnet man es, wenn der Zug/der Bus an einem Bahnhof/einer Haltestelle 5 Minuten (oder sonstwieviel) Aufenthalt hat?

Man könnte einfach einen Zeitraum in die Rolle schreiben. Das steht etwas ausführlicher in einem Entwurf / Notitzen.

Etwas in die Rolle zu kodieren, ist zwar für die Auswertung nicht besonders praktisch, aber für den Mapper einfach. Zudem wären solche OSM-Daten relativ gut mit dem JOSM-Relationseditor überblickbar.

Darüber hinausgehende Fahrtdaten (Ausfälle, Fahrtgeschwindigkeiten, Tarife, Zugteilungen, …) gehören meiner Meinung nach nicht in OSM weil diese Daten kaum noch Geobezug haben und das Datenmodell von OSM dafür nicht geeignet ist. Hier müssen in OSM eher Referenzen geschaffen werden damit Dritte den Bezug von OSM-Daten und verfügbaren Fachdaten herstellen können (vorstellbar wäre die stop_id aus GTFS in OSM zu pflegen, wenn wir mal annehmen, dass die verwendete stop_id allgemeingültig ist wäre).

??

Zumindest in der DB-Auskunft bekomme ich den Busfahrplan bis ins letzte Kuhdorf.

Ich halte aber überhaupt nichts davon, Fahrplandaten in OSM integrieren zu wollen (oder habe ich da was missverstanden?).

  1. sind Fahrplandaten keine Geodaten, sondern Zeittabellen
  2. wird die Datenbank sinnbefreit aufgebläht
  3. werden die Daten kaum jemals vollständig sein
  4. veralten die Daten viel schneller als man sie erfassen kann
  5. sind die Fahrpläne häufig viel zu kompliziert, mit Zeitintervallen ist es nicht getan

Viel sinnvoller ist es, die bereits vorhandenen Online-Daten mit der OSM-DB in Auswertungen zu verbinden.

Extrem wichtig finde ich es, zu Liniensegmenten zu kommen. Dann besteht eine Linie nur noch aus einem Hinweg und einem Rückweg, die jeweils alle Liniensegmente aller Alternativen der jeweiligen Richtung zusammenfassen.

Die Liniensegmente stelle ich mir als Liste der ways vor, die von den Verkehrsmitteln, z.B. Bus, benutzt werden, im Prinzip wie heute die Linie, aber nur als Teilestücke daraus.

Der Nutzen liegt darin, dass die Segmente viel kürzer sind als jetzt die ganzen Linien und von allen Linien referenziert werden können. Dann hat man auch im Zentrum der Großstadt nur noch ein bis drei Liniensegmente (geradeaus, links/rechts abbiegen) am Way und nicht wie heute 20 und mehr. Das erleichtert das Bearbeiten der Straßen ganz erheblich. Auch das Bearbeiten der Segmente wird viel einfacher als jetzt die Linien. Man braucht auch dann, wenn der Bus von der Bundesstraße nach A-Dorf und wieder zurück fährt, keine doppelten Wege mehr, sondern benutzt einfach 2 Segmente, die dann für Hin- und Rückweg referenzierbar sind. Die Bearbeitung in JOSM wird wesentllich einfacher, die Relation kann sortiert werden und es ist sofort ersichtlich, ob das Segment eine geschlossene Linie abbildet oder irgendwo unterbrochen ist. Außerdem erschlägt man mit dem Erstellen eines Segments gleich alle Buslinien, die den Weg benutzen.

Ich finde es auch sinnbefreit, bei OSM alle Fahrtvarianten abbliden zu wollen. Es reicht völlig, jeden befahrenen Weg durch Segmente zu erfassen und alle Segmente in einer Hin- bzw Rückwegrelation zu referenzieren. Welchen Weg welcher Bus wann fährt, ergibt sich aus den Fahrplandaten, und die zu erfassen ist meiner Meinunng nach Unsinn, s.o.

Wolfgang

Von Hin- und Rückweg kann man aus Sicht der Passagiere nicht in allen Fällen reden.

Beispiel: Wenn die Busse folgenden Varianten fahren:

  1. ABCDB (eine große Schleife durch den Zielort)
  2. ABDCB (genauso, nur anders rum)
  3. BCDBA (Umkehrung von 3. aus Sicht des Fahrers)
  4. BDCBA (Umkehrung von 1 aus Sicht des Fahrers)

Für manche Verbindungen ist es so wie für den Fahrer. Aber für die Leute, die nur die Schleife am Zielort benutzen, sind 2. und 4. die Umkehrungen von 1. und 3.

Wir brauchen für dieses Konzept aber keine Unterscheidung von Hin- und Rückweg. Wenn wir die Varianten nicht unterscheiden, müssen wir Hin- und Rückweg auch nicht unterscheiden. Da es dann auch nur noch eine Relation pro Buslinie gibt, ist der Bedarf nach Segmenten auch entfallen. Man anderen Worten: PTv1.

Weide

Die Unterscheidung von Hin- und Rückweg kann je nach Einzelfall tatsächlich entfallen, wenn bei kleineren Straßen dieselben ways benutzt werden.

Dagegen halte ich die Segmente für extrem wichtig.

Vorteil 1: Die Konsistenz eines geschlossenen Weges kann im Segment gut kontrolliert werden, Fehler sind sofort offensichtlich. Ob die Segmente aneinander anschließen, muss extra geprüft werden, aber auch dafür kann man eine Funktion schreiben.

Vorteil 2: Die Segmente können von verschiedenen Buslinien, die abschnittsweise die gleiche Straße befahren, referenziert werden. Damit habe ich dann nur noch eine Segment-Relation am way und nicht 20 Routen, wie es in manchen Innenstädten der Fall ist.

Vorteil 3: Die Segmente sind wesentlich kürzer und können leichter bearbeitet werden.

Die Arbeit für den Mapper, der den way als solches anfassen muss, wird damit entscheidend vereinfacht und die Einstiegshürde für OSM wird etwas gesenkt.

Also gerade nicht PTv1, das ist mit den zerrissenen Wegen, dem ständigen forward/backward und der Vielzahl der Routen am way ein einziger Alptraum, ebenso wie die Vielzahl der Routen am way in PTv2.

Wolfgang

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.