intro

Jannis: selbstständiger Software-Engineer
VBB: Verkehrsverbund Berlin/Brandenburg, recht groß, einige wenige und viele kleine VUs
GTFS-RT-Feed

Problem

bzgl. offenen Daten prinzipiell offen eingestellt (AFAIK 1. VV in DE mit GTFS-Daten, jetzt auch mit GTFS-Pathways), aber wenig Budget & Expertise für "Dateninnovation"
Auskunft: HAFAS von HaCon
Echtzeitdaten: offene API (via HAFAS), aber kein Massenabruf, niedrige Rate Limits und proprietär
bbnavi: OpenTripPlanner-Instanz für Berlin/Brandenburg, braucht Echtzeitdaten
- alle anderen Drittanbieter auch! – MOTIS/Transitous, Citymapper, Transit, polnische Auskunftssysteme, usw.

Austausch mit dem VBB:
1. GTFS-RT generieren, aber dann nicht nur für bbnavi, sondern offen!
2. Datenquelle: HAFAS-Polling ungeeignet, welche anderen Quellen gibt es?
3. VBB-Datendrehscheibe a.k.a. DDS: VDV-453-/-454-API, die Quelldaten von (fast) allen VUs bündelt und weitergibt
kontinuierliche Verarbeitung (Data Pipeline):
1. VDV-IstFahrten abrufen
2. den GTFS-Fahrplandaten zuordnen ("Matching"): Details ggf. später
3. GTFS-RT-TripUpdates im DIFFERENTIAL-Modus generieren
4. TripUpdates zu einem GTFS-RT-Feed bündeln
Überblick über "die Masse an Daten" mittels Metriken, bspw.
- Rate der abgerufenen VDV-IstFahrten
- Anteil der gematchten IstFahrten
- Zahl der TripUpdates im fertigen GTFS-RT-Feed

VDV: Verband deutscher Verkehrsunternehmen, veröffentlicht viele Standards
häufig durch die Industrie getrieben, aber VV/VU wirken auch mit
Standard-Paar für (Massen)Echtzeitdaten:
- VDV-453: Protokoll, Basics, Austausch tagesaktuelle Sollfahrpläne, Abfahrtstafeln & weitere "Sichten"
- VDV-454: Austausch verbundweiter Echtzeitdaten
- seit ca. 2010, neueste Version von 2024
AFAICT teilweise spiritueller Vorgänger von SIRI
XML über (bidirektionales!) HTTP POST

Idee: Datensatz vorlaufend aktualisiert, bildet den gesamten Echtzeitzustand des Netzwerks/VV ab
offener Standard, kommt aus den USA, mittlerweile international entwickelt
Entwicklung offen und recht niederschwellig; Erweiterung braucht ausgeschrieben Vorschlag, 1 Producer, 1 Consumer, dann Abstimmung
Format/Datenmodell eng an GTFS Schedule/Static angelehnt
Encoding Protocol Buffers, bereitgestellt über HTTP

NATS (Message Queue) wegen Lastspitzen, Entkopplung von Abruf/Matching/GTFS-RT-Server
- VPN zur VBB-DDS erlaubt eine IP, Änderungen sehr langwierig -> 1 Server für Abruf nur als "Proxy", anderer Server für GTFS-RT-Generierung
Deployment via Ansible

zunächst: einige Monate warten auf Zugriff
initiale Implementierung in ca 60h, dann über Monate ca. 200h Verbesserungen bis zum stabilen Betrieb
Entwicklung in 3 Services und 1 Library
- VDV-Abruf neu implementiert, geteilt in Abruf-Service und API-Client
- Matching-Service: Code von derhuerst/match-gtfs-rt-to-gtfs (HAFAS-Datenformat-basiert) angepasst, recht regions-agnostisch gehalten
- GTFS-RT-Server größtenteils wiederverwendet
potenziell wiederverwendbar für andere DDS, und ggf. andere Quellformate

undokumentierte Verhaltensweisen der DDS: VDV-Specs nicht ausreichend detailliert, insb.
- welche Variante genutzt wird, etwas im Format auszudrücken
- Timing
- Zustände von Client & Server
- die großen Implementierungen (HaCon, Mentz, usw.) werden als De-Facto-Standards betrachtet
Betrieb durch mich allein, Best Effort: keine HA, keine Uptime-Versprechen
- allerdings: VBB-DDS trotz höherer Professionalisierung auch häufig down
- mein Urteil: dem Projekt angemessen
indirekte Kommunikation mit Beteiligten
1. Kommunikation: ich <-> VBB <-> HaCon
2. "Stille-Post-Effekt" -> extrem zähes Debugging

BVG-Quellsystem kann die Ausfälle nur über HAFAS-proprietäre Flags abbilden, nicht als VDV-453/-454.

auch VDV-453 REF-AUS implementieren, nicht nur VDV-454 AUS
- u.a. deswegen fehlen aktuell viele ausgefallene Fahrten
- häufig nachfragen, welche Protokolle/Features genutzt werden
Daten nun AFAIK auch noch durch das VBB-HAFAS geleitet, um Ausfälle zu normalisieren
- seitens VBB: scope screep, lock-in
black box HAFAS
- Datenverlust? übereifrige Umwandlung durch False Positives?

"Datenprobleme" finden ist hier deutlich schwieriger
- durch Updates des GTFS-Schedule-Feeds keine unveränderliche "Source of Truth"
- Echtzeit: üblicherweise größere Datenmengen
- einzelnen Fehler identifizieren schwierig
  - bspw. ein Fall, in dem das Matching nicht funktioniert
  - besseres Tooling!
Schwierigkeit in der Kommunikation mit den Datenquellen
- "zu Zeitpunkt x war Datensatz y kaputt" hilft oft nicht
- lediglich als wiederkehrendend & allgemein erkannte Fehler werden realistischerweise behoben
"garbage in, garbage out": wenn die VDV-Daten nicht gut genug sind, helfen nur Workarounds

öffentliche Status-Seite für mehr Transparenz
- sogar öffentliche Metriken?
End-to-End-Latenz in den Daten messen
Matching-Rate verbessern, Fernverkehr einbauen?
GTFS-RT-Differential-Modus weiter standardisieren
VDV-Abruf- und Matching-Logik vereinheitlichen mit anderen Projekten
Matching mittels anderer Datenspeicher, z.B. DuckDB?
Rolle & Funktionsweise der DDS dokumentieren:
- Was macht sie eigentlich genau?
- Wie bündelt sie? Wie matched sie?
- Welche Datenformate verarbeitet sie?
- Welche Daten gehen verloren? Fließen die Daten verzögert?
VehiclePositions generieren? – eher unwahrscheinlich

Danke!