OpenStreetMap

Mein Gedanke zu public_transport und mein Wunsch für ein PTv3

Posted by eiskalt-glasklar on 14 April 2020 in German (Deutsch)

Hallo,

ich habe jetzt testweise mehrere Haltestellen im Bundesgebiet in verschiedenen Verkehrsverbünden auf PTv2 umgestellt. Dabei sind mir in der Praxis zahlreiche Schwächen des ÖPNV-Modells, wie es in PTv2 verwendet wird, aufgefallen, was teilweise an unklaren/ungenauen Definitionen liegt, teilweise aber auch an konzeptuellen Schwächen oder Planungsfehlern. In der Praxis wäre ein PTv3, mit dem diese Kinderkrankheiten ausgemerzt werden, nicht nur von meiner Seite, sondern auch von Auswertern deutlich wünschenswert.

  1. Der erste konzeptuelle Fehler ist, dass bei PTv2 nicht bedacht wurde, dass der Kartennutzer ein visuelles Feedback sehen möchte, auf welcher Seite sich eine Bushaltestelle befindet.

Das ist vor allem für Fußgänger-Routing wichtig, denn vor allem im ländlichen Raum (z. B. Standenbühl), aber auch in städtischen Regionen (z. B. Hanau Kastanienallee) können Bushaltestellen teilweise sehr weit voneinander entfernt sein. Hier nur einen einzelnen Node für die gesamte Bushaltestelle verwenden, wie es bspw. Google bei seinem Public Transport-Modell macht, oder den Node auf die Straße zu setzen ohne visuelles Feedback, in welche Richtung die Busse fahren, wird der realen Praxis nicht gerecht.

Bei einem Bahnhof stellt sich das Problem so nicht: ich kann mich einfach auf einen Bahnsteig stellen und auf den Zug warten und er wird im Regelfall auch kommen. Bei einer Bushaltestelle sehe ich im schlimmsten Fall den Bus davonsausen weil ich mich an eine Bushaltestelle gestellt habe die nur in eine Fahrtrichtung bedient wird (selbst so passiert!).

  1. Das Mappen von public_transport=platform als Linie/Fläche muss aufgegeben werden und public_transport=platform ausschließlich für das Mapping des Haltestellenschildes als physikalisches Objekt verwendet werden.

Das ist eine der Dinge, die mich am meisten an PTv2 wurmen, dass sich manche Nutzer nunmehr berufen fühlen, jede Bushaltestelle als Fläche zu mappen, nur weil es dort ein Busbord gibt (oder im schlimmsten Fall nicht mal das, der bestehende Bürgersteig wird einfach OSM-technisch zur Busplattform umfunktioniert). Damit wird vom bisherigen, einfach auszuwertenden Datenmodell abgewichen und auf ein deutlich komplexeres Modell umgestellt. Dieses Modell kommt mit einigen Problemen daher:

a. In Deutschland müssen bis 2022 alle Bushaltestellen barrierefrei ausgebaut werden. Das heißt, es wird zukünftig an allen Bushaltestellen einen Busbord geben. Diesen Busbord nunmehr zur Busplattform umzufunktionieren, ist ähnlich wie das Mappen von Bordsteinen als barrier=kerb, das aus den gleichen Gründen sehr umstritten ist. Dabei wird public_transport=platform auf der Standardkarte, anders als barrier=kerb (das aber auch nur durch den Missbrauch von barrier=, ähnlich barrier=line für Markierungen auf Fußballfeldern) nicht einmal gerendert, außer man fügt noch highway=platform dazu - und dann sind wir endgültig beim Mappen für den Renderer angekommen. Gleichzeitig wird highway=bus_stop nicht auf Linien oder Flächen gerendert, sodass man entweder einen zusätzlichen Node für highway=bus_stop hinzufügen muss (sieht PTv2 aber nicht vor), oder die Unterscheidung nach Fahrtrichtung aufgeben und highway=bus_stop auf die Straße klatschen muss (hierzu siehe oben).

b. Für Datennutzer sind flächenhafte public_transport=platform schwieriger auszuwerten. Reichte es bisher zum Rendern einer Buslinie aus, alle Linien der Relation auszuwählen, müssen nunmehr Linien mit dem Tag public_transport=platform ausdrücklich ausgeschlossen werden. Den Effekt sieht man auf der OSM-Webseite auf der Verkehrskarte, wo alle linien- und flächenhafte public_transport=platform wunderschön rot aufleuchten. Auch der JOSM-Validator ist von diesem Ergebnis wenig begeistert.

c. Für große Busbahnhöfe ist das Modell schlicht untauglich. Auf großen Busbahnhöfen gibt es Warteplattformen mit mehreren Haltepositonen für Bussen. Es ist aber im OSM-Datenmodell nicht möglich, derselben Warteplattform mehrere Haltepositionen zuzuordnen. Bei Bahnhöfen wird dieses Problem, m. E. mehr schlecht als recht, durch das Auftrennen des Bahnsteigs und dem Mappen als Relation gelöst, bei Busbahnhöfen ist das so nicht möglich. Die einzige Lösung ist, doch sowohl die Warteplattform als auch die Haltestellenschilder als public_transport=platform zu mappen, und damit führt man PTv2 endgültig ad absurdum.

  1. Im ländlichen Raum Deutschlands gibt es Bushaltestellen, die nur in eine Richtung ausgeschildert sind, die Busse aber trotzdem in beide Richtungen halten (z. B. Kerzenheim Grauwaldsiedlung).

Dieser Fall ist im PTv2 schlicht überhaupt nicht vorgesehen. PTv2 geht davon aus, dass für jede Richtung eine Halteposition und ein Bushaltestellenschild existiert. Bei den von mir erwähnten Haltestellen scheitert das System komplett. Praktisch sind derartige Bushaltestellen bzw. Buslinien, die solche Haltestellen bedienen, nicht auswertbar.

  1. Das Mappen von ÖPNV-Sonderformen (AST, Ruftaxi, Rufbus) ist mit PTv2 nicht möglich.

Diese Sonderformen sollen nach Lesart PTv2 mit share_taxi getaggt werden. Das ist aus zweierlei Gründen problematisch. Erstens bezeichnet share_taxi im Englischen ein Buschtaxi/Marschrutka/Dolmus, also etwas ganz anderes als das was man im Deutschen unter einem Ruftaxi versteht. Zum anderen wird das sture Taggen mit share_taxi der tatsächlichen Vielfalt der ÖPNV-Sonderformen nicht gerecht. Es gibt Linien, bei denen für Gruppen nach Voranmeldung auch ein Standardbus eingesetzt werden kann (z. B. viele Ausflugslinien), es gibt Linien, die für Gruppen nicht geeignet sind weil nur ein Großraumtaxi bis acht Personen verwendet wird, und schließlich gibt es auch reguläre Buslinien die lediglich durch ein Großraumtaxi bedient werden ohne dass man das im OSM-Datenmodell unterscheiden könnte, obwohl das für Wandergruppen unzweifelhaft eine wichtige Information ist.

Hinzu kommt noch, dass es Buslinien gibt, die in der HVZ (z. B. Schülerverkehr) als regulärer Bus, außerhalb der HVZ aber als Ruftaxi-System bedient werden. Nach PTv2-Lesart müsste man diese Linie in eine Bus- und eine Ruftaxi-Linie (zwei route_master etc. pp.) aufteilen da eine Route nicht beides gleichzeitig sein kann, obwohl im Fahrplan nur eine gemeinsame Linie für beide Bedienungsformen verzeichnet sind.

Das größte Problem ist aber dass Ruftaxi-Linien ohne festen Fahrtweg, bei denen man sich zwischen zwei beliebigen Haltestellen befördern lassen kann, im PTv2-System schlicht nicht vorgesehen sind. Damit ist das Mapping moderner Bedienungsformen im OSM-Datenmodell derzeit unmöglich.

  1. Niemand hat jemals definiert, wie eine Bushaltestelle zu heißen hat. Folglich findet sich in OSM ein wildes Sammelsurium, teils sogar innerhalb derselben Buslinie. Eine vernünftige Auswertung ist so unmöglich.

Aus meinen alten, gedruckten Liniennetzplänen weiß ich dass es gelebte Praxis ist, den reinen Haltestellennamen ohne Gemeindenamen und ohne Stadtteil auf der Karte darzustellen. Folglich mappe ich das so auch als name=. Einige Anwendungen, wie z. B. das automatische Erstellen einer sogenannten “Perlschnur” als Fahrtweg einer Buslinie, funktionieren so nicht vernünftig wenn, wie häufig im ländlichen Raum, die Hälfte der Haltestellen einfach “Ortsmitte” heißt. Es ist aber derzeit nicht möglich, aus der Bushaltestelle auf den Orts- oder Gemeindenamen zu schließen. ref_name, was zur Verknüpfung mit der Fahrplanauskunft der Deutschen Bahn verwendet wird, ist nicht maschinell auswertbar und scheitert zudem an der höchst unterschiedlichen Benennungspraxis der einzelnen Verkehrsverbünde (der VRN ist hier besonders grottig). Es wäre wünschenswert, durch zusätzliche Tags und einer klaren Definition in diesem Punkt Klarheit zu schaffen.

  1. Die derzeitigen Proposals für ein neues public_transport stochern in der Suppe rum, ohne das eigentliche Problem zu lösen.

a. stop_positions sind nicht nur für das Fußgängerrouting, sondern auch für weitergehende Anwendungen unverzichtbar. Bushaltestellen an Straßenecken, aber auch solche an Busbahnhöfen (wie bereits erwähnt) lassen sich ohne stop_position nicht vernünftig routen. Deshalb bin ich für eine Beibehaltung aller stop_position.

b. Es muss auch weiterhin möglich sein Bushaltestellen mit externen Datenbanken außerhalb der OSM zu verknüpfen z. B. für eine Fahrplanauskunft ab der gewünschten Bushaltestelle. Hierzu braucht man auch weiterhin stop_area Relationen. Eine Abschaffung oder Streichung dieser Relationen lehne ich entschieden ab.

c. Der komplette Verzicht auf Fahrtwegmapping ist diskutabel, schneidet uns aber von einigen Usecases für public_transport-Mapping ab, wie z. B. das Rendern von Liniennetzplänen. Ich habe zuhause zahlreiche ältere, gedruckte Liniennetzpläne und es wäre durchaus vorstellbar, so etwas auch auf OSM-Basis zu realisieren.

d. Es gibt auch in heutiger Zeit Linien, deren Fahrpläne nicht ohne weiteres im Internet erhältlich sind. Hierunter fallen nach meiner Praxis z. B. viele Ruftaxi-Linien im VRN-Gebiet. Hierfür kann OSM einen deutlichen Mehrwert darstellen. Ein kompletter Verzicht auf Buslinien wäre ein schwerer Schlag, vergleichbar mit dem Verzicht des Mappings von Wanderrouten.

e. Man muss aber den Begriff “ÖPNV” näher definieren und sich z. B. fragen ob Fernbusse noch unter diesen Begriff fallen und ob wir Fernbusse, ähnlich wie z. B. Fluglinien, wirklich in OSM haben wollen.

Falls mir noch etwas einfällt, ergänze ich es…

Login to leave a comment