Repository navigation
live datenquellen
Zusätzliche Bahn-Livedaten für Gleisänderungen, Verspätungen und Haltausfälle ohne Registrierung oder API-Schlüssel. Umsetzung und Quellenprüfung: 10.10.2026, auf Routely main bei 8ecd87b1727d7a95d6fb09d40bb8541ece0c4695.
Träwelling bleibt für Konto, Check-ins, Fahrtidentität und vollständige Haltfolge zuständig. Routely ergänzt aktuelle eindeutig zuordenbare Bahn-Halte über die öffentliche DBF-Abfahrtstafel. Der Dienst verwendet IRIS und besitzt offenen Quellcode. Die App benötigt dafür keinen DB-Marketplace-Zugang, API-Key oder eigenen Proxy.
Die ursprüngliche Empfehlung für den offiziellen DB-Timetables-Zugang wurde nach der Nutzerpräzisierung verworfen: Dieser Zugang benötigt Registrierung und Anwendungsschlüssel. RIS::Journeys/Boards benötigen zusätzlich Freigabe und Vertrag. Der anonyme Dienst v6.db.transport.rest antwortete im Entwicklungsabruf mit HTTP 503; seine aktuellen DB-Vendo-Daten liefern in Bahnhofstafeln außerdem keine durchgehend belastbare operative Zugnummer für den hier benötigten Abgleich. Diese Dienste werden nicht eingebaut.
app/src/main/kotlin/de/traewelling/app/data/dbf/DbfRealtimeRepository.ktapp/src/main/kotlin/de/traewelling/app/data/model/StopRealtimeInfo.ktapp/src/main/kotlin/de/traewelling/app/data/model/Models.ktapp/src/main/kotlin/de/traewelling/app/data/repository/TraewellingRepository.ktapp/src/main/kotlin/de/traewelling/app/service/TripTrackingService.ktapp/src/main/kotlin/de/traewelling/app/service/JourneyTimeResolver.ktapp/src/main/kotlin/de/traewelling/app/viewmodel/RealtimePresentation.ktapp/src/main/kotlin/de/traewelling/app/viewmodel/StatusDetailViewModel.ktapp/src/main/kotlin/de/traewelling/app/ui/screens/StatusDetailScreen.ktapp/src/main/kotlin/de/traewelling/app/util/PreferencesManager.kt
Träwelling bezieht Fahrplandaten selbst von Transitous. Die am 10.10.2026 untersuchte veröffentlichte Backend-Revision 4d602796da8409017314cc771b1127d169155f02 liest im Stopovers-Endpunkt gespeicherte Werte. Sein minütlicher Scheduler wählt eingecheckte aktive Fahrten; der Default-Mindestabstand für die nächste Transitous-Aktualisierung ist zwei Minuten. Eine HTTP-Anfrage an Träwelling erzwingt keine neue Providerabfrage. Eingesetzte Produktionsrevision, Konfiguration und Queue-Laufzeiten wurden nicht beobachtet; die Codekonfiguration ist kein gemessenes Produktionsintervall.
Ein anderer Zugang zu demselben Transitous-Feed erweitert dessen Echtzeitabdeckung nicht. DBF ergänzt dagegen eine IRIS-Bahnhofstafel. Der Entwicklungsabruf am 10.10.2026 lieferte anonym HTTP 200 für Hannover Hbf mit Minutenverspätungen und abweichendem geplantem/aktuellem Gleis. Dies belegt die Erreichbarkeit und die konkreten gelieferten Felder zu diesem Zeitpunkt, keine garantierte höhere Aktualität jeder Fahrt.
GET https://dbf.finalrewind.org/<EVA>.json?version=3&no_related=1&past=1
Die dokumentierte JSON-Version 3 ist stabil. no_related=1 ist zwingend: Ohne diese Einschränkung kann DBF Halte verwandter Bahnhöfe aufnehmen, während die JSON-Zeile selbst keine Stationskennung enthält. Die EVA stammt aus station.identifiers.de_db_ibnr; interne Träwelling-Stations-IDs sind keine EVA.
past=1 nimmt auch die vergangene Stunde auf; der Standard-Vorblick beträgt 180 Minuten. Bei verspäteten Fahrten wird der Fensterabgleich am belegten verzögerten Ereignis geprüft, sodass eine vor mehr als 20 Minuten geplante, jetzt aktuelle Fahrt nicht allein wegen ihrer Verspätung entfällt. DBF hält IRIS-Echtzeit laut geprüftem Quellcode selbst etwa 70 Sekunden im Cache. Der zusätzliche Clientcache kann deshalb keinen sekundengenauen Providerstand garantieren.
Die Zuordnung verwendet positive operative CheckinInfo.journeyNumber, EVA und vorhandene Ankunfts-/Abfahrts-Sollzeiten. Linienbezeichnungen wie RE1, Namen oder Koordinaten ersetzen diese Identitäten nicht. Nur eindeutige Treffer aus dem aktuellen Bahnhofstafel-Zeitfenster werden übernommen. Die API liefert Sollzeiten lediglich als HH:mm: Das Fahrtdatum stammt deshalb aus dem vorhandenen konkreten App-Ereignis und wird gegen den Abrufhorizont geprüft. Mehrdeutige Tage, widersprüchliche Zeiten und nicht eindeutig auflösbare Sommerzeitstunden bleiben ohne Zusatzdaten.
Die Tafel enthält nullable Minutenverspätungen, platform, scheduledPlatform, missingRealtime und ein zusammengefasstes isCancelled. Fehlende Daten bleiben unbekannt. Ein synthetischer Nullverspätungswert beziehungsweise ein mit dem Plan identisches Gleis belegt nicht selbstständig neue Echtzeit. Version 3 liefert keine getrennten Ankunfts-/Abfahrtsausfälle; daraus wird kein erfundenes Teilausfallmodell erzeugt. Ein bestätigter kompletter Haltausfall kann ergänzt werden; ein bloßes isCancelled=false beweist keine vollständige Rücknahme eines möglichen Teilausfalls.
- Die Quelle ist standardmäßig aktiv und über Zusätzliche Bahn-Livedaten abschaltbar. Es wird ausschließlich die benötigte öffentliche Bahnhofstafel angefragt; Bearer-Token, Kontoinformationen und Gerätepositionen gehen nicht an DBF.
- Der Prozess teilt Cache und laufende Abrufe zwischen Detailansicht und Begleitungsservice. Höchstens zehn Request-Starts in 60 Sekunden und einer je EVA in 60 Sekunden entsprechen der aktuellen Dienstvorgabe; auch fehlgeschlagene Starts zählen. Die Quote gilt je App-Prozess, keine flottenweite Kapazitätszusage.
- Erfolgreiche Tafeln werden mindestens 60 Sekunden wiederverwendet. Fehlversuche und
Retry-Afterbegrenzen erneute Anfragen. Wenige zeitnahe Bahnhöfe und eine kurze Gesamtfrist begrenzen den Zusatzabruf; historische Fahrten, andere Verkehrsmittel, fehlende Kennungen und uneindeutige Treffer behalten Träwelling-Werte. - Zeiten, Gleise und Ausfälle erhalten getrennte Quell-/Abrufinformationen, ausschließlich wenn das jeweilige Feld übernommen wurde. Ein erfolgreicher HTTP-Abruf ohne passenden Wert erneuert keine beibehaltenen Fremdwerte.
- Zusatzdaten werden nur lokal angezeigt und für die bestehende Begleitung verwendet. Sie lösen keinen Check-in-PUT aus. Manuelle Korrekturen und lokale GPS-Zeiten behalten ihre bisherige Priorität.
- Der Änderungsmonitor behandelt einen bekannten Wechsel der jeweiligen Zeit-/Gleisquelle als neue Vergleichsbasis. Der Rückfall auf einen anders bezogenen Wert erzeugt keine scheinbare Verspätungsverbesserung, Gleisänderung oder Ausfallrücknahme. Neu bestätigte komplette Ausfälle bleiben meldbar.
- Session-, Fahrt- und Statusrevision werden auch nach dem optionalen Zusatzabruf geprüft. Verspätete Antworten dürfen keinen neuen Check-in oder eine andere Sitzung überschreiben.
StopRealtimeInfo.fetchedAtMillis beschreibt den erfolgreichen Clientabruf, nicht den Zeitpunkt einer Änderung bei DB oder Transitous. providerUpdatedAtMillis bleibt ohne belastbaren Beleg leer; ein Störungsmeldungs-Zeitstempel ist keine Prognosezeit.
Die Detailansicht bündelt API-Quellen und Abrufalter in einer zentralen Karte. Sie berücksichtigt getrennte Zeit-, Gleis- und Ausfallmetadaten, nennt alle beteiligten Quellen und verwendet konservativ den ältesten Abruf; unbekannte Abrufzeiten und Abruffehler bleiben sichtbar. Die Haltezeilen wiederholen keine Quellen-/Altertexte unter Ankunft, Abfahrt, Gleis oder Ausfall. Das frühere tagesabhängige grüne LIVE-Badge ist ersetzt. lastUpdated wird nur nach erfolgreichem Halteabruf erneuert. Ein Gleisvergleich zeigt weiterhin beispielsweise Gleis 7 statt 5; Herkunft und Alter von Gleisen sind im Modell von Zeitwerten getrennt.
GPS-Schätzungen stehen in der Timeline mit ≈, GPS-Beobachtungen mit einem GPS-Symbol und manuelle Zeiten mit einem Stift direkt neben der Uhrzeit. Bei den Headerzeiten bleiben diese lokalen Quellen ausgeschrieben. TalkBack erhält die genaue ereignisbezogene Zeitquelle samt API-Abrufalter, Ist-/Planzeit und Verzögerung als gemeinsame Ansage; Gleis- und Ausfallbadges behalten ihre vorhandene Herkunft über unsichtbare Semantik. Alte Fahrtcache-Einträge ohne Abrufmetadaten gelten als unbekannt, statt beim Neustart als frisch gestempelt zu werden.
Vorhandenes OkHttp, Gson und Coroutines; keine zusätzliche Android-Bibliothek, kein DB-Zugangsspeicher und kein mitgelieferter Proxy. DBF ist ein öffentlich betriebener Dienst mit begrenzter Kapazität; sein Quellcode ermöglicht einen späteren eigenen Betrieb. Die Softwarelizenz beschreibt den Dienstcode und ist kein pauschaler Lizenznachweis für alle zugrunde liegenden Bahndaten.
- TODO: Neue Quelle auf echten Fahrten mit Gleiswechsel, Ausfall, Mitternacht und Rücknahmen mit Träwelling vergleichen. Eine einzelne erfolgreiche Tafel beweist weder Vollständigkeit noch einen festen Aktualitätsvorsprung.
- TODO: Abdeckung und Belastung des öffentlichen Dienstes bei wachsender Zahl von Installationen bewerten; bei Bedarf die quelloffene Software selbst betreiben.
- Unklar: Tatsächliches Produktionsalter der Träwelling-/IRIS-Prognosen; Client-Abrufzeit ist kein Provider-Aktualitätsbeleg.
- TODO: Möglichen Datenverlust in der vorhandenen Stopover-Duplikatauswahl gesondert prüfen; aktuell bewertet sie nicht alle Echtzeitfelder.