derhuerst · May 28, 2025 19:27 · May 28, 2025 · May 28, 2025
diff --git a/notes.md b/notes.md
@@ -2,6 +2,7 @@
 
 - [Jannis](https://jannisr.de): selbstständiger Software-Engineer
 - VBB: Verkehrsverbund Berlin/Brandenburg, recht groß, einige wenige und viele kleine VUs
+- [GTFS-RT-Feed](https://production.gtfsrt.vbb.de)
 
 ---
 

diff --git a/notes.md b/notes.md
@@ -0,0 +1,150 @@
+# intro
+
+- [Jannis](https://jannisr.de): selbstständiger Software-Engineer
+- VBB: Verkehrsverbund Berlin/Brandenburg, recht groß, einige wenige und viele kleine VUs
+
+---
+
+# 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](https://bbnavi.de): OpenTripPlanner-Instanz für Berlin/Brandenburg, braucht Echtzeitdaten
+	- alle anderen Drittanbieter auch! – [MOTIS](https://motis-project.de)/[Transitous](https://transitous.org), Citymapper, Transit, polnische Auskunftssysteme, usw.
+
+---
+
+# Lösungsansatz
+
+- 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-`IstFahrt`en abrufen
+	2. den GTFS-Fahrplandaten zuordnen ("Matching"): Details ggf. später
+	3. GTFS-RT-`TripUpdate`s im `DIFFERENTIAL`-Modus generieren
+	4. `TripUpdate`s zu einem GTFS-RT-Feed bündeln
+- Überblick über "die Masse an Daten" mittels Metriken, bspw.
+	- Rate der abgerufenen VDV-`IstFahrten`
+	- Anteil der gematchten `IstFahrt`en
+	- Zahl der `TripUpdate`s im fertigen GTFS-RT-Feed
+
+---
+
+## Exkurs VDV-453 & VDV-453
+
+- 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
+
+---
+
+## Exkurs GTFS Realtime (GTFS-RT)
+
+- 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
+
+---
+
+## Architektur
+
+- 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
+
+[![architecture diagram](./architecture.png)](https://github.com/OpenDataVBB/gtfs-rt-infrastructure/blob/main/readme.md)
+
+---
+
+# Umsetzung
+
+- 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](https://github.com/OpenDataVBB/vdv-453-nats-adapter) und [API-Client](https://github.com/OpenDataVBB/vdv-453-client)
+	- [Matching-Service](https://github.com/OpenDataVBB/gtfs-rt-feed): Code von [`derhuerst/match-gtfs-rt-to-gtfs` (HAFAS-Datenformat-basiert)](https://github.com/derhuerst/match-gtfs-rt-to-gtfs) angepasst, recht regions-agnostisch gehalten
+	- [GTFS-RT-Server](https://github.com/OpenDataVBB/nats-consuming-gtfs-rt-server) größtenteils wiederverwendet
+- potenziell wiederverwendbar für andere DDS, und ggf. andere Quellformate
+
+---
+
+# Lessons Learned
+
+- 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
+
+---
+
+## Lessons Learned: Streiks & geplanten Ausfällen
+
+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](https://github.com/OpenDataVBB/gtfs-rt-infrastructure/issues/3)
+	- 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?
+
+---
+
+## Lessons Learned: Datenqualität und Praxisprobleme
+
+- "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
+
+---
+
+## Wie geht es weiter? & offene Fragen
+
+- ö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!
+
+---
+
+## Sonstiges
+
+- [MOTIS-VDV-Client](https://github.com/motis-project/nigiri/tree/d326ac9fcf1ad852c53ecff69625a0dc428c14a6/src/rt/vdv)
No results found