[Talk-de] ÖPNV-Relationen in OSM

[Stephan Wolff]

Moin,

ich habe schon viele Stunden Arbeit in die Erstellung und Pflege von
ÖPNV-Relationen (Bus-, Bahn- und Fährlinien) investiert. Leider ist
der Erfolg meiner Bemühungen (und der vieler anderer Mapper) gering.

Die Relationen beschreiben entweder nur eine Richtung einer Linie,
beide Fahrtrichtungen oder sogar verschiedene Linienvarianten in
einer Relation. Die Straßensegmente sind (teilweise falsch) mit
"role"-Tag "forward"/"backward", manchmal mit "route", "default",
"alternate" etc. versehen. "stop_position"- und "platform"-Punkte
haben "role"-Tags "", "stop", "platform" aber auch "stop:22" oder
"platform:60:alternate:1". Die Haltestellen sind teils zwischen
den ways, oft auch unsortiert am Ende. "name"-Tags sind fast immer
willkürliche Textfolgen aus ref/operator/network/direction.
"from" und "to" fehlen teilweise oder sind uneinheitlich gebildet.
Einzig die Liniennummer ist eindeutig im "ref"-Tag enthalten.
Viele Relationen sind durch spätere Bearbeitung der ways beschädigt.

Die Daten reichen aus, um eine Karte mit Liniennummern an Straßen und
Haltestellen zu erzeugen. Unsortierte Relationselemente, unsinnige
"role"-Angaben und kleine Lücken erzeugen allenfalls kleine
Kartenfehler, die der menschliche Betrachter meist ignorieren kann.
Für solche ÖPNV-Karten würde aber auch ein einfaches "lines"-Tag am
way bzw. an der Haltestelle genügen.
Für andere Anwendungen sind die Daten ungenügend. Die vielen Tagging-
Varianten machen es unmöglich, die Daten korrekt zu interpretieren.
Bei vielen Relationen ist nicht erkennbar, ob zwei Haltestellen vom
selben Bus angefahren werden oder ob sie zu zwei alternativ bedienten
Teilstrecken gehören. Ein großer Teil der Relationen ist fehlerhaft.
Selbst wenn eine Relationen eine unverzweigte Strecke abbildet und
keine Fehler hat, kann man die Angaben nicht zur Fahrtplanung nutzen,
da keine Informationen zu Betriebszeiten, Takt oder Fahrzeiten bietet.
Viele gedruckte Reiseführer enthalten dagegen grobe Informationen wie
"bis <Ziel> ca. 70 Min., Mo-Sa 6-22Uhr, So 8-20Uhr, tagsüber alle 15
Minuten, nach 18Uhr alle 30 Min.", die auch Jahre nach dem Druckdatum
noch nützlich sind. Solche Informationen wären auch in OSM möglich.

Leider können sich die relativ großen Relationen des ÖPNV auch
unmittelbar störend auswirken. Wenn eine Straße Teil mehrerer
Relationen ist, überlege ich es mir oft zweimal, ob ich in wenigen
Minuten eine Verbesserung der Straßendaten mache und dann ein
Vielfaches der Zeit in die Überprüfung und Anpassung der Relationen
stecken muss. Ein OSM-Neuling wird sich oft gar nicht herantrauen.
Wenn man etwas an Relationen geändert hat, ist immer ein Konflikt beim
Upload möglich, der von vielen Mappern nicht korrekt gelöst werden kann.
Mehrere Streckenvarianten der Buslinie sich durch Kopieren und Ändern
der ersten Relation leicht erstellt, aber müssen danach einzeln
gepflegt werden.

Die Qualität der ÖPNV-Relationen hat sich nach meiner Einschätzung in
den letzten zwei Jahren nicht gebessert. Die Zahl der Tagging-Varianten
ist gestiegen, die Fehlerquote ist unverändert hoch. Es erscheint mir
sinnlos, wie bisher weiterzumachen.

Ich habe nur vage Ideen, wie das Problem zu lösen wäre:
- eine Editorerweiterung, die defekte Routen erkennt und die langweilige
Arbeit bei der Erstellung/Reparatur deutlich vereinfacht (für JOSM wäre
das mit viel Programmierarbeit vielleicht möglich, aber bei anderen
Editoren?)
- ein Bot, der jede Nacht die unterbrochenen Relationen repariert, die
"role"-Tags richtig setzt und nicht automatisch korrigierbare Relationen
meldet (auch sehr schwierig umzusetzen). Die Mapper könnten unbelastet
editieren :-)
Beide Varianten wären mit einer Vereinheitlichung des Relationsschemas
auf das vom Programm unterstützte Format verbunden.
- Umstellung auf ein stark vereinfachtes Relationsschema, bei dem nur 
die Haltepunkte, aber nicht die Stecken Elemente der Relation sind.
Solche Relationen wären viel einfachen zu erstellen, zu pflegen und viel
robuster gegen Änderungen am Wegenetz, aber es wäre zur Kartenerstellung
eine neue Nachbearbeitung mit Routingalgorithmen nötig (dieses Schema
hat schon ein anderer vorgeschlagen, ich finde die Referenz aber gerade
nicht).
Bei allen Varianten könnte man Tags für Betriebszeiten
(operating_hours), Takt(frequency?), Fahrzeiten (duration) und wenn
möglich eine URL des Fahrplans (url:timetable?) hinzufügen.
oder
- Verzicht auf gerichtete ÖPNV-Linien in OSM. Dann genügt eine leicht
zu pflegende Tag-basierte Lösung um Liniennummern mit Haltestellen und
Fahrstrecken zu verbinden. Gegebenenfalls Zusammenarbeit mit einem
anderen Projekt für ÖPNV.

Viele Grüße
Stephan