Wer DBF aus einem fahrenden Zug heraus aufruft, kann seit heute nur per GPS-Position Informationen zu diesem Zug erhalten – zumindest in den meisten Fällen und mit ein paar Einschränkungen. Ich möchte hier das Konzept dahinter erläutern.

Da über GTFS derzeit nur Solldaten zur Verfügung stehen und das HAFAS Zugradar lediglich nach beliebigen Fahrten im Umkreis sucht, ohne dabei konkrete Strecken zu berücksichtigen, greift die DBF-Implementierung nicht darauf zurück.

Stattdessen hat sie als einzige API-Abhängigkeit die Ankunfts-/Abfahrtstafel für Bahnhöfe und berechnet alles weitere selbst. Auch bei Abschaltung des HAFAS Zugradars bleibt sie funktionsfähig.

Abbildung von Positionen auf Nachbarstationen

Kern der Lokalisierung ist eine Datenbank, die Deutschland in ca. 200m × 300m große Rechtecke einteilt¹. Für jedes Rechteck, das mindestens eine Bahnstrecke enthält, listet sie alle Bahnhöfe auf, die von einem diese Bahnstrecke passierenden Zug planmäßig als nächstes angefahren werden. Eine Position auf dem Tunnel durch den Teutoburger Wald bei Lengerich enthält beispielsweise unter anderem

• Lengerich (Westf) und Natrup-Hagen (RB66),
• Münster (Westf) Hbf und Osnabrück Hbf (IC/ICE Linien 30 und 31) sowie
• Essen Hbf und Hamburg Hbf (IC-Verbindung Hamburg – Ruhrgebiet ohne Unterwegshalte).

Die Datenbank beruht derzeit überwiegend auf dem von NVBW bereitgestellten SPNV GTFS-Liniennetzplan. Dieser enthält erfreulicherweise auch RE- und RB-Linien außerhalb von Baden-Württembeg. Erweitert wird sie mit einer (leider unfreien und unvollständigen) Menge an IC/ICE- und S-Bahn-Verbindungen. Für Hinweise zu weiteren offenen Datenquellen mit Liniennetzangaben bin ich dankbar.

Bestimmung von Zugkandidaten

Auf Basis einer GPS-Position werden zunächst die Nachbarstationen aus der Datenbank geholt und dann die Ankünfte der nächsten zwei Stunden an jeder Station abgefragt. Dieser Vorgang kann bei einer großen Menge an Stationen einige Sekunden dauern, da die Abfragen nicht parallel stattfinden. Zwar wäre die dadurch ausgelöste zusätzliche Last verglichen mit den restlichen (durch Menschen verursachten) HAFAS-Anfragen noch nicht einmal messbar, zu viele parallele Anfragen von einer einzigen IP dürften aber dennoch nicht gerne gesehen werden.

Für jede Zugfahrt sind Soll- und Ist-Zeit der Ankunft an der angefragten Station sowie die Namen und Soll-Abfahrtszeiten aller vorherigen Stationen bekannt. Züge, die an mehreren der angefragten Stationen verkehren, sind mehrfach vorhanden und werden zu einer einzigen Zugfahrt vereinigt. Nun geht es daran, für jeden Zug abzuschätzen, ob er sich gerade an der angefragten Position befinden könnte oder nicht.

Da die Datenbank mit Paaren von Stationen gefüttert wird, fliegt zunächst jeder Zug raus, der nur eine der angefragten Stationen passiert. Bei solchen Zügen ist sehr wahrscheinlich, dass sie die gesuchte Position auf ihrer Strecke nicht passieren. Anschließend wird für jeden Zug mit Hilfe der (bekannten) Verspätung an der angefragten Station die (unbekannte) verspätung an den vorherigen Unterwegshalten geschätzt und anhand dieser Echtzeitdaten bestimmt, zwischen welchen beiden Unterwegshalten er sich gerade befindet. Ebenso wird für jedes Paar von Unterwegshalten die Entfernung zwischen der angefragten Position und der Luftlinie zwischen den Halten bestimmt.

Jetzt fliegen alle Züge, deren aktuelle geschätzte Position sich nicht zwischen dem Paar von Unterwegshalten mit der kürzesten Entfernung zur angefragten Position befindet. Denn diese sind gerade sehr wahrscheinlich nicht auf dem richtigen Streckenabschnitt. Ebenso werden Züge verworfen, die sich noch an der Startstation befinden und nicht innerhalb der nächsten fünf Minuten losfahren. Eine S-Bahn, die erst in einer Stunde losfährt, ist wohl kaum gerade auf einer Bahnstrecke unterwegs oder auch nur einstiegsbereit am Bahnsteig.

Für die verbleibenden Züge wird die aktuelle Position auf der Luftlinie zwischen ihren Halten geschätzt. Dabei gehe ich von konstanter Geschwindigkeit aus, da ich keine Beschleunigungsprofile oder Streckengeschwindigkeiten kenne. Anschließend werden die Züge sortiert nach der Entfernung zur gesuchten Position aufgelistet.

Genauere Positionsabschätzung

Mit Verwendung des tatsächlichen Linienverlaufs einer Fahrt anstelle der Luftlinie zwischen Unterwegshalten ließe sich die Position noch viel genauer abschätzen und insbesondere bestimmen, ob die Route eines Zuges überhaupt die gesuchte Position enthält – wenn nicht, kann er direkt verworfen werden, auch wenn er nur wenige km neben der gesuchten Position auf einer anderen Bahnstrecke entlangfährt.

Diese Verbesserung ist derzeit nicht implementiert, da das die Menge notwendiger API-Anfragen nochmals erhöhen würde und ich zunächst testen möchte, ob die Ergebnisse mit linearer (Luftlinien-)Interpolation bereits hinreichend nützlich sind. Außerdem kommt es regelmäßig vor, dass das HAFAS die Linie selbst falsch einschätzt und z.B. einen ICE auf einer nicht elektrisierten Nebenbahn (statt der einige km entfernt verlaufenden, aber insgesamt längeren, elektrisierten Hauptbahn) platziert.

Ebenso wäre es auf Dauer interessant, anstelle der Entfernung zur Position die Zeit bis zum Erreichen (oder seit dem Erreichen) der Position als Gütemaß zu verwenden. S-Bahnen und ICE sind ja durchaus unterschiedlich schnell unterwegs. Das steht noch auf der Todo-Liste.

Quelltext

Die Implementierung ist noch ein wenig frickelig und undokumentiert, aber selbstverständlich auf GitHub verfügbar: derf/geolocation-to-train.

Fußnoten

¹ Der Einfachheit halber werden auf drei Nachkommastellen gerundete GPS-Koordinaten genutzt. Das resultierende Gitternetz ist unseren Breitengeraden nicht quadratisch.

Travel-Status-DE-VRR-1.20.tar.gz (signature)

• efa-m, EFA: Accept "stopID" stop type
• EFA: Add proximity_search (useProxFootSearch) option

Travel-Status-DE-VRR-1.19.tar.gz (signature)

• Result: Add ->train_no accessor

Travel-Routing-DE-VRR-2.20.tar.gz (signature)

• EFA/Route/Part: Add occupancy accessor
• efa: Show expected occupancy, if available

Travel-Status-DE-VRR-1.18.tar.gz (signature)

• EFA: "place" is now optional
• Result: Add ->occupancy accessor
• efa-m: The "place" argument is now optional
• efa-m: Show expected vehicle occupancy, if available

Travel-Status-DE-DBWagenreihung-0.06.tar.gz (signature)

• DBWagenreihung: Add train_descriptions accessor
• Wagon: Add train_subtype accessor

Travel-Status-DE-IRIS-1.54.tar.gz (signature)

• Add stations DKP, DRBS, DSBG, KWHD, NCBD, TENS, XLHW

Travel-Status-DE-DBWagenreihung-0.04.tar.gz (signature)

• Distinguish between IC2 KISS / IC2 Twindexx and ICE T 411 / ICE T 415

Travel-Status-DE-DBWagenreihung-0.05.tar.gz (signature)

• Distinguish between ICE 3 403 series 1/2 and ICE T 411 series 1/2

Travel-Status-DE-IRIS-1.53.tar.gz (signature)

• import station name changes and station removals from Winterfahrplan 2021

Travel-Status-DE-IRIS-1.52.tar.gz (signature)

• get_station_by_name: Fix crash (unhandled exception) when the station name is an invalid regular expression

Travel-Status-DE-IRIS-1.51.tar.gz (signature)

• Add BER airport stations
• Rename Schönefeld airport to BER Terminal 5

Travel-Status-DE-IRIS-1.50.tar.gz (signature)

• Add station Brunnen(Oberbay)
• Incorporate station name and eva number changes from DB IRIS (affects nine stations)
• Add geocoordinates to 17 stations previously lacking those

Travel-Status-DE-IRIS-1.49.tar.gz (signature)

• Add station Jaderberg

Travel-Status-DE-IRIS-1.48.tar.gz (signature)

• Add stations Neuruppin Seedamm (temporary, teardown expected Dec 2020), Amriswil, and Baar(CH)

Travel-Status-DE-IRIS-1.47.tar.gz (signature)

• Work around (probably incorrect) IRIS coupling of Norddeich and Norddeich Mole stations

Travel-Status-DE-DeutscheBahn-3.01.tar.gz (signature)

• Fix support for ÖBB and other backends which recently switched from two- to four-digit years

The build instructions on the sigrok Wiki only work for Python2, which is past its end of life date. To build libsigrok with Python bindings for Python3, you need to set PYTHON=python3 when running configure.

The dependency list is also slightly different:

sudo apt-get install git-core gcc g++ make autoconf autoconf-archive \
  automake libtool pkg-config libglib2.0-dev libglibmm-2.4-dev libzip-dev \
  libusb-1.0-0-dev libftdi1-dev check doxygen python3-numpy \
  python3-dev python-gi-dev python3-setuptools swig default-jdk

"python-gi-dev" is not a typo -- the package covers both Python2 and Python3.

Side note: Installing libserialport-dev instead of building your own version as documented on the Wiki seems to work fine.

Travel-Status-DE-DeutscheBahn-3.00.tar.gz (signature)

• Result: The date, datetime, and time accessors now report realtime data if available
• Result: Add sched_date, sched_datetime, and sched_time accessors for schedule data

Travel-Status-DE-IRIS-1.46.tar.gz (signature)

• Document LWP::Protocol::https dependency
• Discourage building with Geo::Distance 0.21. Geo::Distance 0.21, released on 7 Mar 2019, is the only release using GIS::Distance's distance_km method -- which was removed on 9 Mar 2019 in GIS::Distance 0.14