Fehlerkorrekturen in TRAVIC

Seit TRAVIC vor 2 Jahren gestartet ist, erreichen uns regelmäßig Meldungen von netzkundigen Nutzern, die von der Realität abweichende Fahrtverläufe festgestellt haben. Für diesen Input sind wir sehr dankbar. Da es uns für die Routen an Referenzdaten mangelt, haben wir fast keine Möglichkeit, Zug- oder Busfahrten im Einzelnen zu prüfen. Oft wirken Fahrtverläufe zwar auf den ersten Blick korrekt (Züge nutzen einleuchtende Strecken, Straßenbahnen folgen ohne "Knicke" oder Wenden auf freier Strecke ihren Gleisen), weichen im Detail aber deutlich vom tatsächlichen Verlauf ab. In den meisten Fällen fehlt uns einfach die Kenntnis der lokalen Gegebenheiten, um diese Fehler zu erkennen. Vor allem bei Buslinien auf dem Land ist meistens nur für Ortskundige ersichtlich, ob ein Bus in TRAVIC die richtige Route nimmt oder ob er sich durch eine für den Verkehr gesperrte, enge Altstadtgasse pflügt.

Wieso weichen Routen von der Realität ab?

Für die meisten eurpäischen Ländern liegen uns die Fahrplandaten nur so vor, wie sie dem Fahrgast präsentiert werden: als Liste von Ankunfts-/Abfahrtszeiten an den Bahnhöfen. Wir haben weder die Information, wo diese Routen genau geografisch verlaufen noch über welche "Wegpunkte" sie im Detail führen. Die einzigen geografischen Stützpunkte, über die wir verfügen, sind die planmäßig angefahrenen Stationen. Vor allem bei Zugfahrten, die sehr weite Strecken ohne Halt zurücklegen (z.B. Fernzügen) gleicht das Finden der korrekten Strecke einem Ratespiel und kann in Einzelfällen vom wirklichen Fahrtverlauf abweichen.

Ein Beispiel: Aktuell verkehren in TRAVIC viele ICEs zwischen Hannover und Hamburg über Nienburg und Rotenburg, obwohl sie eigentlich über Celle und Lüneburg fahren.

Wie kann ich helfen, das Routing zu verbessern?

Die Fahrtverläufe generieren wir einmalig zum Fahrplanwechsel für das ganze Jahr. Als Ausgangsdatensatz nutzen wir OpenStreetMap. Das Gleis- und Straßennetz in Europa ist dort nahezu vollständig abgedeckt und bildet eine ideale Grundlage für TRAVIC.

Grundsätzlich nutzen wir einen Kürzester-Weg-Algorithmus um zwischen 2 aufeinanderfolgenden Stationen den geografischen Fahrtverlauf zu generieren (wie hier beschrieben). Da im Bereich ÖV der kürzeste Weg zwischen zwei Stationen jedoch selten der tatsächlich Fahrtverlauf ist, nutzen wir neben Heuristiken (z.B. der Anzahl durchfahrener Stationen) auch OSM-Attribute, um die Menge der möglichen Wege zu verkleinern.

Es gibt mehrere Möglichkeiten, zur Verbesserung von TRAVIC beizutragen.

Durch Korrekturen in OSM

Eine große Zahl von Fehlern kann behoben werden, indem die zugrundeliegenden OSM-Daten entweder korrigiert oder angereichert werden. Dies umfasst beispielsweise das Hinzufügen von neuen OSM-Relationen oder die Korrektur von evt. falschen Weg-Attributen.

Die Bearbeitung von OSM-Daten ist mehr oder weniger unkompliziert mit verschiedenen Tools möglich. Am komfortabelsten und plattformunabhängigsten ist aktuell iD.

Um den Editor zu starten, sollte man sich zunächst auf www.openstreetmap.org registrieren.

Nach der Registrierung kann über den "Edit"-Button der Editor gestartet werden.

Nun muss man in den Bereich, den man bearbeiten möchte, hineinzoomen. In unserem Fall möchten wir die Relation für den ICE 22 bearbeiten. Der Kartenausschnitt sollte also z.B. um die Gegend bei Celle eingestellt werden, wo der ICE 22 auf seiner Fahrt von Hannover nach Hamburg verkehrt.

Ein Klick auf das Gleis öffnet links die Bearbeitungsanzeige für die Attribute der eigentlichen Geometrie ("way") und listet außerdem die Relationen auf, zu der der Weg gehört. In OSM können verschiedene Objekte mittels Relationen zusammengefasst werden, so dass es z.B. möglich ist, bestimmte Zugstrecken, die aus hunderten Einzelgeometrien bestehen, zu einem Objekt zu gruppieren.

In diesen Fall ist schnell ersichtlich, weshalb die Routenfindung unserer Algorithmus nicht den korrekten Weg findet: die ICE-Relationen sind ohne Leerzeichen notiert (ICE25 statt ICE 25). Dies entspricht nicht der Benennung im Fahrplan und folgt außerdem nicht dem Vorschlag in der OSM-Wiki.

Durch Anklicken der Relation kann sie bearbeitet und ein Leerzeichen eingefügt werden.

Danach synchronisiert ein Klick auf "Save" die Änderungen in die OSM-Datenbank. Beim nächsten Durchlauf unseres Routings sollten Fahrzeuge der ICE 22-Relation den korrekten Weg nehmen.

Durch Zuordnung von Fahrzeugtypen

Ein Problem ganz anderer Art stellt die Zuordnung von Fahrzeugtypen dar. Die Fahrplan-Rohdaten, mit denen wir TRAVIC speisen, kennen keine eindeutigen Fahrzeugtypen. Es ist uns also ohne manuelle Vorarbeit nicht möglich, zu sagen, ob ein Fahrzeug eine Fähre, ein Bus, eine U-Bahn oder ein Zug ist. Für das Finden der richtigen Route ist das jedoch sehr wichtig. Wenn wir z.B. den Fahrtverlauf für einen Bus suchen, blenden wir Geometrien von Zuggleisen völlig aus. Ist nun ein Zug fälschlicherweise als Bus markiert, kann die korrekte Route nicht mehr gefunden werden.

Ein relativ einfaches Beispiel ist unten zu sehen.

Die S4 bei Salzburg ist seit dem Fahrplanwechsel in den Fahplandaten ohne Leerzeichen geschrieben, daher wird beim internen Lookup des Fahrzeugtyps jetzt "Subway" statt korrekterweise "Zug" eingetragen. Das hat zur Folge, dass für die S-Bahn überhaupt keine Geometrie gefunden wird und direkte Luftlinienverbindungen als Fallback geschrieben werden.

Die meisten Fälle sind etwas tiefer verborgen als der oben gezeigte. Wenn solche Fälle erkannt werden, wäre uns mit einer Lookup-Tabelle vom Routennamen (in TRAVIC die kleingedruckte Bezeichnung direkt unter dem Fahrtziel) zum Fahrzeugtyp geholfen. Diese kann uns einfach per Mail zugesandt werden. Die von uns verwendete Fahrzeugtypen entsprechen dem GTFS-Standard und werden hier aufgelistet. Der Fahrzeug-Typ für Züge ist beispielsweise "2".

Eine mögliche Lookup-Tabelle könnte also so aussehen:

S1,2
S2,2
S3,2
S4,2
S5,2

Durch Mapping von Fahrzeugnamen

In einigen Fällen entsprechen die Routennamen die im Fahrplan (und damit in TRAVIC) erscheinen nicht den Routennamen, die dem Fahrgast am Bahnhof angezeigt werden und die auch in OSM vorhanden sind. Dies gilt insbesondere für Nebenbahnen, die nicht von der DB betrieben werden. Die Korrektur von Routennamen in OSM-Relationen bringt in solchen Fällen natürlich keine Verbesserungen. Auch sollte man auf keinen Fall Relationen in OSM eintragen, die auf den internen Bezeichnungen des Fahrplans beruhen.

Stattdessen wäre uns hier wieder mit einer Lookup-Tabelle geholfen, die die häufig kryptischen Bezeichnungen des Fahrplans in die gängigen Bezeichnungen vor Ort übersetzt.

Für den Raum Freiburg z.B. böte sich eine solche Lookup-Tabelle an (die Breisgau-S-Bahn wird dem Fahrgast als BSB präsentiert):

DPS 88353,BSB
DPS 88348,BSB

Auch diese kann uns einfach per Mail zugesandt werden.

Fazit

Wer über Basiskenntnisse im Umgang mit OSM verfügt, kann viele der Abweichungen in TRAVIC selbst korrigieren. Natürlich muss einschränkend nochmals erwähnt werden, dass wir aufgrund der riesigen Menge an Daten die Fahrtverläufe nur einmal im Jahr zum Fahrplanwechsel generieren. Es kann also u.U. lange dauern, bis Korrekturen in OSM auch in TRAVIC erscheinen.

Zusätzlich sollte nicht unerwähnt bleiben, dass ein ebenfalls großer Anteil der Ungenauigkeiten im Routing seinen Ursprung in unserem Algorithmus hat. Vor allem das Nutzen zusätzlicher OSM-Attribute wie z.B. der Maximalgeschwindigkeit o.ä. ist noch nicht vollständig umgesetzt. Hier erwarten wir auf unseren Seite in den nächsten Monaten große Verbesserungen.

29.1.2016
Mehr zum Thema
3 min Lesezeit | Lösung

mobilityCMS

Ein CMS zugeschnitten auf Unternehmen des öffentlichen Verkehrs.

weiterlesen
3 min Lesezeit | Blog

performance.now()

Zwei Frontend-Entwickler von geOps machten sich nach Amsterdam auf, um an der performance.now() teilzunehmen, einer zweitägigen Konferenz mit vierzehn erstklassigen Sessions, die die wichtigsten Erkenntnisse zur Web-Performance von heute behandeln.

weiterlesen
6 min Lesezeit | Blog

Webkarten als PDF exportieren und drucken

Schon seit einiger Zeit bieten einige unserer Apps den Export unserer Karten im PDF-Format. Dieser Artikel stellt unsere Lösungen für diverse Neuerungen dieser Funktion vor.

weiterlesen
9 min Lesezeit | Blog

Snapping stops to vehicle trajectories

How to snap points to a line string in a given order and what it has to do with quality assurance when importing public transport schedules.

weiterlesen
7 min Lesezeit | Blog

Using Redis Subscriptions efficiently in Python

Inspired by the websockets broadcast feature we built a subscription multiplexer for redis subscriptions to subscribe to Redis channels and patterns once for all relevant clients.

weiterlesen
3 min Lesezeit | Blog

React 18 Unterstützung für create-react-web-component

Wir wollen fünf Jahre alte Abhängigkeiten des Projekts trafimage-maps aktualisieren. Aber es scheint, dass eine Projektabhängigkeit veraltet ist. Was sollen wir tun? Das Projekt reparieren oder etwas anderes verwenden? Wir haben uns entschieden, das Projekt zu reparieren und der Gemeinschaft etwas zurückzugeben.

weiterlesen

Kontakt

geOps AG
Solothurnerstrasse 235
CH-4600 Olten

fon: +41 61 588 05 05
mail: info@geops.ch
geOps GmbH
Bismarckallee 10
D-79098 Freiburg im Breisgau

fon: +49 761 458 925 0
mail: info@geops.de
Impressum | Datenschutz | Bedingungen