PTv3: Stopposition und Platform

Im Sinne der Ziele gemäß PTv3: Zielsetzung eines modifizierten ÖPNV Modells möchte ich hier Veränderungen im Themenbereich Stopposition und Platform zur Diskussion stellen.

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

  • Nutzen von Stoppositionen

  • Erweiterte Stopposition

  • Gruppierung von Stop und Platform

  • Rollenzusätze zu stop und platform

  • Zukunft von highway=bus_stop

Grundsätzlich können Stoppositionen einen gewissen Nutzen haben:

  1. Zuordnung des korrekten Weges, auch dort wo eine Umkreissuche nach dem der Platform nächsten Weg falsche Ergebnisse liefert.

  2. Anwendungen sparen den Aufwand der Umkreissuche

  3. Festlegung, wo dass Fahrzeug an der Platform steht. Dies ist z.B. für Fußgänger-Router hilfreich. Auch läßt sich damit ggf. die Position barrierefreien Zugangs bezogen auf das Fahrzeug bestimmen, wenn wir die Einstiegshöhe in die Route aufnehmen und die Bahnsteighöhen unter Verwendung von railway=platform_edge taggen.

  4. Z.B. bei einer Segmentierung könnten die Stoppositionen innerhalb von PTv3 hilfreich sein.

Bei PTv2 ist der Nutzen jedoch stark reduziert, da die Stopposition nicht als zwingend notwendig definiert ist, und somit Anwendungen doch wieder Algorithmen zur Umkreissuche bereithalten müssen. Weiterhin ist nicht definiert, wo der Stopposition-Node zu plazieren ist (z.B. in Zugmitte oder an der Zugspitze), und damit kann aus seiner Position nicht die wirkliche Position ermittelt werden, wo dass Fahrzeug stopt.

Letzteres ist in PTv3 leicht zu beheben wie z.B. durch ein Tag, das definiert, wo die Stopposition gemappt wurde.
Die Stopposition verbindlich zu machen, würde in PTv2 den Aufwand durch Duplizierung der Daten und kompliziertere Routen deutlich erhöhen. Grundsätzlich verbindlich werden kann die Stopposition auch in PTv3 wohl nur, wenn man eine Lösung findet, den Zusatzaufwand weitgehend zu vermeiden.

Aus meiner Erfahrung kann ich sagen, dass dieser Tag niemals flächendeckend verwendet werden wird.
Nebenbei, was ist mit variablen Haltepositionen? Beispielsweise an Bus- oder Tramhaltestellen, die für mehrere Fahrzeuge hintereinander ausgelegt sind. Oft gibt es dann keine festen Haltepositionen, sondern das erste Fahrzeug, was ankommt, hält ganz vorne und alle weiteren dahinter. Und was ist mit variablen Haltepositionen, wie z.B. am Kölner Hbf?
Oder, wenn eine Linie mit verschiedenen Zugkonfigurationen gefahren wird, die dann an anderen Stellen am Bahnsteig ihre Haltetafeln haben?

Außerdem, wenn man z.B. den Standort der Haltetafel erfasst, muss man auch die dazugehörige Zuglänge kennen, um belastbare Aussagen über den mittleren Fußweg zum Ausgang treffen zu können. Einige Haltetafeln haben zwar Zuglängen angegeben, das sind aber auch nur Maximalwerte. Und dann übertrag das ganze mal auf Länder wie Indien, wo du locker Bahnsteiglängen von 600-700 Meter und mehr findest.

Es tut mir leid, aber ich sehe nicht, wie man ohne extremen Aufwand die Detaillgenauigkeit signifikant verbessern kann. Klar, eine Definition muss her. Daher schlage ich persönlich den typischen mittleren Ein- und Ausstiegspunkt der stop_position vor. Diese Position kann man dann nämlich ohne großartige weitere Schritte direkt in ein Routingprogramm einspeisen, und das ist ja das Ziel der ganzen Angelegenheit.

Viele Grüße

Stop und Platform Nodes separat anzulegen und dann auch noch in passender Reihenfolge in die Routen einzufügen, stellt in PTv2 einen hohen Aufwand dar.

Daher hier eine Ansatz, um den den Aufwand ohne Informationsverlust zu reduzieren:

Wenn wir vom Plattform-Node zur Stopposition eine Linie zeichnen und statt der beiden Nodes nur die Linie Taggen, sparen wir die Duplizierung der Daten und bauchen nur diese Linie in die Route aufnehmen. Der offene Linienanfang wäre als Platform-Node zu interpretieren und das mit dem highway/railway verbundene Linienende als Stopposition.

Diese Linie könnte wie eine Stopposition getaggt werden, daher nenne ich sie hier erweiterte Stopposition.

Man könnte die erweiterte Stopposition gedanklich als Projektionslinie der Platform auf den Weg oder als Fahrgastfluss zwischen Platform und Fahrzeug ansehen.

Wenn die Linie an einem Node einer als Weg gemappten Platform beginnt, sollte die erweiterte Stopposition so definiert sein, dass kein Platform-Node impliziert wird, sondern die gemappte Platform implizit als mit in die Routen aufgenommen gilt, in denen die erweiterte Stopposition enthalten ist.

Die erweiterte Stopposition hat noch weitere Vorteile:

  • Da die Linie eine Richtung hat, kann man die Ausdehnung des Haltebereichs nach rechts und nach links bei Bedarf durch Tags spezifizieren.

  • Bei Buslinien wird eine Verwechslung von Stoppositionen der beiden Fahrtrichtungen vermieden, da diese bei der erweiterten Stopposition eindeutig erkennbar ist.

  • Stop und Platform werden auch bereits ohne Route gruppiert, was zum Rendern nützlich sein dürfte.

Zum Einen wird die Verbreitung sehr davon abhängen, was der Editor anfordert (z.B. Felder in iD oder Validator in JOSM) und ob die Daten von Anwendungen genutzt werden. Zum Anderen sind fehlende Tags auch nicht schlimm. Dann ist wenigstens klar, dass keine Info vorhanden ist.

Dann beschreibt man halt per Tag, dass die Halteposition entsprechend ausgedehnt ist, z.B. über die ganze platform-Länge.

Als alternative Stopposition in die Route aufnehmen.

Könnte man mit Routenvarianten je nach Zugkonfiguration und separaten Stoppositionen realisieren. Dann sollten wir aber sehr leichtgewichtige Varianten, die nicht gleich die ganze Route duplizieren. Die Zuglänge kann man an der Route taggen.

Allerdings hat die Verwendung mehrerer Haltetafeln häufig den Sinn, die Züge zum Beispiel mittig am Bahnsteig auszurichten oder mit dem hinteren Ende auszurichten. Da kann man dann einfach eine Stopposition verwenden, die dies beschreibt.

Erstens können wir sowas nicht einfach umdefinieren, da wir dann Informationen in die vorhandenen Stoppositionen hineininterpretieren, die so nicht vorhanden war.
Zweitens ist auch der mittlere Punkt ggf. stark von der Zugkonfiguration abhängig, wenn z.B. alle Züge am Bahnsteigende halten.

Das System mit fester Halteposition funktioniert auch nur in Deutschland. Wenn man über den Tellerrand schaut, z. B. in Frankreich werden einfahrenden Züge die Gleise nach dem Prinzip “wer zuerst kommt, mahlt zuerst” zugewiesen. Der Zug kann heute auf Gleis 1 sein, morgen ist er auf Gleis 12 und am nächsten Tag dann wieder auf Gleis 8. Das ist derzeit mit PTv2 nicht vernünftig darstellbar.

Nicht mal hier in Deutschland: die Züge der Nahestrecke kommen in Mainz Hbf an drei verschiedenen Gleisen an und es gibt keinen Zusammenhang mit der Fahrstrecke oder den ausgelassenen Halten, die getrennte Varianten sinnvoll machen würden. Wir sollten in PTv3 alternative Platforms angebbar machen und auf die Stop-Positionen komplett verzichten. Wo bei den Altdaten nur Stops vorliegen, zählt man die einfach als (evtl. völlig ausreichenden) Näherungswert der Platform.

Diese “just-in-time”-Zuweisung der Gleise wird sich sowieso weltweit immer mehr ausbreiten.

Ich halte die Idee von slhh, die Beziehung Halteposition ↔ Bahnsteig mit einer Linie zu kennzeichnen für eine gute Idee. Zu den Einwänden:

Ich halte es für die Zukunft sowieso für unabdingbar, dass wir einen möglichen Entwurf in einem internationalen Forum diskutieren. Woher sollten wir denn die Mappingpraktiken in allen betroffenen Gebieten kennen (von den Betriebsabläufen vor Ort ganz zu schweigen). Insofern ist dieses Forum (also users:Germany) für mich sowieso höchstens eine »erste Instanz«, wenn man so will.

Halte ich auch für eine richtige Lösung. Natürlich gibt es dann eine Vielzahl von Stops in den Linienrelationen, aber das nur für einige wenige Bahnhöfe. Der Großteil an Stationen einer Linie sind meist (Innenstadtlinien ausgenommen) einfache Stationen bzw. Haltepunkte, die dann nur noch einfach erfasst würden. Ich sähe auch den Vorteil, dass solche komplexen Strukturen eher in Siedlungszentren auftreten - Orte, die viele Mapper leicht erreichen können, weil sie sie sowieso passieren.

Das nehme ich nicht so wahr; meine Wahrnehmung ist sicherlich subjektiv. :slight_smile:
In einem solchen Fall könnte man sich überlegen, nur die drei häufigsten Positionen anzugeben. Falls es sich um verschiedene Gleise handeln sollte, ist dem Nutzer dennoch geholfen, weil er erst einmal eine grobe Orientierung bekommt: Er weiß, in welche Richtung er/sie sich orientieren muss, weil häufig das Nachbargleis genommen wird. Überlegung dahinter: Die Züge einer Linie kommen ja normalerweise aus derselben Richtung, damit ist die Anzahl der möglichen Bahnhofsgleise von vornherein beschränkt, weil von einer Bahnhofseinfahrt nicht unbedingt alle Bahnsteiggleise erreicht werden können. Der Benutzer weiß also: Es ist Gleis 13, 14 oder 15, welche sich auf der nördlichen Bahnhofsseite befinden. Welches Gleis es genau sein wird, werden wir in OSM sowieso nie sicher sagen können, weil wir kurzfristige Sperrungen nicht erfassen würden.
Für Busbahnhöfe würde dasselbe gelten: Der Bus kann zwar meist alle Bussteige erreichen (ist evtl. zu hoch für eine Überdachung einzelner Bussteige), würde aber nicht von der Einfahrt bis zum hintersten Steg fahren, wenn er sowieso immer am vordersten halten würde.
Ich gebe zu, dass man immer Szenarien konstruieren kann, in denen die OSM-Daten falsch sind, es ist nur die Frage, ob die Daten überhaupt dafür gemacht sind, jeden möglichen Bussteig bzw. jeden möglichen Bahnsteig zu erfassen. Ich meine Nein.

Das mag insbesondere für einige große Fernbahnhöfe gelten, aber für die meisten Stationen wird dies aus Infrastuktur- oder betrieblichen Gründen nicht sinnvoll sein.

Ein PTv3 sollte beide Fälle gut unterstützen. Alternative Stoppositionen bzw. Platforms sollten also möglich sein.

Nur Platforms zu verwenden hatte ich auch in Erwägung gezogen, bin aber zu keiner überzeugenden Gesamtlösung gekommen. Man würde wohl auch dabei die Haltebereiche durch Rollenzusätze definieren können. Zum Beilspiel durch Bezug auf Gleisnummern oder in railway=platform_edge aufzunehmende Bezeichnungen, wenn wir mal von dem Problem absehen, das Gleisnummern oder offizielle Abschnittsbereichnungen dem Mapper unbekannt sein könnten.

Die Hauptprobleme sehe ich eher in der fehlenden direkten Zuordnung zum Fahrweg insbesondere im Busbereich, da bei breiten Straßen die Straßenlienie weit vom Platform-Node entfernt sein kann und andere highway näher liegen könnten.
Im Eisenbahnbereich tritt das Zuordungsproblem zwar grundsätzlich häufiger auf, da mehrere Gleise an einem Bahnsteig liegen können, ist aber durch Zuordnungen zu Gleisnummern oder platform_edge leichter lösbar. Ein platform_edge kann auch abgesehen vom Rechenaufwand einfach dem Gleis zugeordnet werden, da der Abstand nur ca. 1,5m beträgt. Leider kann aber der Abstand der zugrundeliegenden Nodes bei hinreichend geradem Gleis fast beliebig groß sein, was den Rechenaufwand erheblich erhöht, da sehr viele Wege auf ihren Abstand zu prüfen sind.

Die fehlende Fahrwegzuordnung macht es schwierig Editortools anzubieten, die zum Beispiel einen Fahrweg auf Basis der Haltestellenliste autorouten, um diesen dann manuell nur noch nachbearbeiten zu müssen.
Auch bei der Validierung würde die fehlende Fahrwegzuordnung wohl Nachteile bringen.

Auch eine Segmentierung wird erschwert, da sich die Stoppositionen ideal als benannte Segmenttrennstellen anbieten. 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. Nachdem ich längere Zeit mit Segmentrelationen experimentiert hatte und nach Umstellung ganzer Gegenden nicht sehr zufrieden war, 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.

Hier mal einige Überlegungen zur Gruppierung der Stop- und Platform-Member in der Route.
PTv2 ermöglicht genau je einen Stop- und Platform-Member, die zudem auch noch in bestimmter Reihenfolge zueinander in der Relation stehen müssen, zu einer Haltestelle zu kombinieren. Dies hat einige Nachteile:

  • Je ein Member ist unzureichend, wenn wir an alternative Stoppositionen/Platforms, geteilte Platforms (z.B. Teil auf Brücke) oder die spanische Lösung (beidseitig Bahnsteige) denken.
  • Die Komplexität der manuellen Sortierung ist nicht nur auf die Haltestellenfolge beschränkt, sondern muss auch noch die Gruppierung sicherstellen.

Daher folgender Ansatz zur Gruppierung:

Alle Member mit gleichem Namen werden als ein Halt aufgefasst.

Leider gibt es noch einige Ausnahmefälle, wie z.B. Ringlinien oder separater Ausstiegshalt, wo mehrfach an der gleichen Haltestelle gehalten wird. Gemäß wiki kann den Rollen mit “:” abgetrennt eine Haltnummer angehängt werden, was aber inzwischen technisch überflüssig ist. Um die Ausnahmefälle korrekt abbilden zu können, können wir dies in PTv3 jedoch wieder aufgreifen und die Regel wie folgt erweitern:

**Alle Member mit gleichem Namen werden als ein Halt aufgefasst, sofern keine unterschiedlichen Haltnummern in der Rolle angegeben werden.
**
Dabei sollte der Validator es als Fehler angesehen, wenn bei gleichnamigen Membern nur teilweise Haltenummern angegeben sind. Es wäre jedoch nicht nötig (aber zulässig), alle Haltestellen zu numerieren. Die gleiche Haltnummer darf auch bei mit anderem Namen wiederholt verwendet werden. Beispielsweise könnten bei einer schleifenförmigen Linie mit zweimal durchfahrenen Abschnitt die Halte im ersten Durchgang die Endung “:1” und die des zweiten Durchgangs die “:2” bekommen.

Das fasst es sehr schön zusammen.

Ich bezweifle aber immer noch, dass wir tatsächlich zwei Arten von Objekten brauchen. Enden der Fußgängerströme reichen in den Routen. Na ja, eigentlich nicht “Fußgänger”: Auch Radfahrer und bei Fähren sogar Motorräder und Autos treten als Passagiere auf und müssen beim Umsteigen und am Anfang und Ende der Reise geroutet werden. Dieses Passagierrouting sollte der Zweck eines PTv3 sein.

Bloß nicht! Finger weg von “gleicher Name”. Das ist in PTv2 schon eine der wichtigsten Fehlerquellen. Trotz dauernder Reparaturbemühungen finden sich ständig kaputte PTv2-Routen wegen der dort genutzten Namensgleichheit.

Diese Haltestellennummern sind in PTv2 nicht überflüssig – sie sind falsch.

Und in PTv1 wurden sie nachträglich drangeklatscht, um die dort eigentlich nicht vorgesehenen Reihenfolgeinformationen unterzubringen. Dabei hätte von Anfang an klar sein müssen, dass das in PTv1 nur bei einfachen Linien finktionieren kann.

Ich denke, dass das Verwirrung hervorufen wird. Da kann man eher in der Rolle einen Präfix “+” für ergänzende Haltestellenangaben (z.B. weitere Bahnsteigteile) und einen Präfix “alt_” für alternative Haltestellenangaben (wieder mit eigenen “+”-Objekten) nehmen.

Mir fällen nur wenige Beispiele ein, bei denen das ein Problem sein könnte:

  • Bussteige im Busbahnhof, der Bus fährt vor/nach dem Halt im U um den zentral angelegten Bussteig
  • Bahnstationen, bei denen das Fahrzeug am Bahnsteig anhält, dann weiterfährt, nach dem Bahnsteig wendet (Schleife, Wendedreieck oder Spitzkehre) und erneut den Bahnsteig passiert (auf irgendeiner Seite). Beim Bus wäre das auch denkbar.
  • Die Haltestelle liegt nahe einer Selbstüberschneidung der Route. Das wäre bei einem fiktiven Zug der Fall, der von Rehfeld (bei Falkenberg/Elster) über Falkenberg (Elster) oben und die Schleife nach Falkenberg (Elster) unten fährt (Karte).

Wie du weiter unten schreibst, brauchen sie die Umkreissuche jetzt schon. Es wäre also eine Vereinfachung für Mapper.

Bahnsteighöhen werden in großer Zahl schon an den Bahnsteigflächen erfasst. Meist – nicht immer – sind sie auf beiden Seiten gleich.

Das verstehe ich nicht.

Mir fällt jetzt spontan noch folgender Fall ein:
Bus fahrt auf einer sehr breiten Straße ohne bauliche Trennung, hält unmittelbar vor einer Kreuzung und biegt dort nach rechts in eine sehr schmale Straße ein. Der Platform-Node dürfte ggf. näher an der schmalen Straße liegen und somit fälschlicherweise dieser zugeordnet werden.

Insgesamt stimme ich aber zu, dass es nur relativ wenige Problemfälle gibt, wenn denn der Fahrweg komplett und unversehrt in der Route vorhanden ist. Problematisch wird es, wenn der Fahrweg (teilweise) fehlt, wie zum Beispiel für ein Autorouting-Tool, um dem Mapper beim Erstellen des Fahrweganteils der Route zu helfen.

Das Rendering der Public-Transport Haltestellen ist auch bisher an dem Problem gescheitert, dass man erst die Routen analysieren müßte, um PTv2 Haltestellen zu rendern.

Vielleicht gibt es auch Anwendungen aufgrund solcher Schwierigkeiten einfach nicht. Wir haben doch ohnehin das Problem, dass das ÖPNV-Mapping bisher zu wenig genutzt wird, was die Motivation der Mapper entsprechend senkt.

Viele Bahnsteige sind teilerhöht und da wird die Positionierung des Fahrzeugs für die Barrierefreiheit wichtig.

Bei einer Segmentierung ist es extrem wichtig, die Segmente identifizieren zu können. Da bieten sich SToppositionen ideal als Trennstelle an, da sie benannt sind und der Editor daraus automatisch eine Bezeichnung für das Segment erzeugen kann, die das Segment für den Mapper identifizierbar macht.

Platforms sind dagegen keine geeigneten Elemente, um eine Trennstelle festzulegen. Wenn man eine Plattform als Start und Ende in Segmentrelation aufnimmt, ist das Segment nicht mehr in sich verifizierbar. Ein Segment, das in der Nähe einer Platform endet, und ein zweites Segment, das in der Nähe derselben Platform beginnt, müssen nicht lückenlos verbunden sein oder können sich gegenseitig überlappen oder überschneiden.

Grundsätzlich denke ich auch, dass wir, von Ausnahmefällen wie spanische Lösung oder geteilte Platform abgesehen, langfristig nur noch erweiterte Stoppositionen in der Route benötigen würden. Für eine Umstellungsphase dürfte es aber hilfreich sein, wenn PTv3 auch noch die bisherigen Stop/Platform-Paare zulässt.

Das halte ich für zu einseitig auf diese Anwendung ausgerichtet und wenn wir uns auf diese Anwendung beschränken würden, bräuchten wir auch den Fahrweg nicht mehr, zumindest wenn wir die Haltestellen so definieren, dass sie auch ohne Fahrweg eindeutig sind.

Die Frage wäre, ob dies nicht akzeptabel wäre, wenn wir in PTv3 diese Gruppierung viel seltener gebrauchen. Der vorgeschlagene namensbasierte Ansatz hätte den Vorteil, das die Gruppierung von Sonderfällen mit der bisherigen Gruppierung übereinstimmt. Dies dürfte eine Umstellung auf PTv3 deutlich erleichtern.

Im Sinne des Proposals mag das sein, im Sinne des Wikis eher nicht und was die Community als richtig ansieht, mag ja nochmal anders sein.

Da erhöht man aber wieder die Komplexität der Memberreihenfolge, da nicht nur die Haltestellenfolge, sondern auch die Gruppierung wieder eingeht.