Fahrgäste interessiert Ihre Datenarchitektur nicht. Sie interessiert nur eins: Kommt der Bus wirklich, und wann? GTFS-RT (die Echtzeit-Erweiterung des GTFS-Standards) macht aus der GPS-Position Ihrer Busse genau diese Antwort: in der App, auf der Haltestellenanzeige, in Google Maps. Doch zwischen dem Fahrzeug auf der Straße und dem Bildschirm des Fahrgasts muss vieles korrekt ablaufen. So funktioniert es in der Praxis, und hier hakt es typischerweise.
Vom GPS-Signal zum Bildschirm des Fahrgasts
Jeder mit Pysae ausgestattete Bus sendet seine Position in regelmäßigen Abständen. Diese Rohposition ist nur ein Punkt auf der Karte. Damit daraus nützliche Echtzeitinformation wird, muss sie dem geplanten Angebot zugeordnet werden: welche Linie, welche Fahrt, welche Haltestelle als nächste kommt und wie das im Vergleich zum Fahrplan aussieht. In diesem Zuordnungsschritt steckt die eigentliche Intelligenz. Eine Position ohne Kontext sagt dem Fahrgast nichts; eine Position mit „Linie 3, 4 Minuten Verspätung, an Ihrer Haltestelle in 6 Minuten“ verändert sein gesamtes Erlebnis.
Die drei GTFS-RT-Feedtypen
GTFS-RT ist nicht ein einzelnes Ding: Es sind drei zusammengehörige Feeds, und die meisten Netze brauchen alle drei:
- Trip Updates: prognostizierte Ankunfts- und Abfahrtszeiten pro Haltestelle. Daraus entsteht „nächster Bus in 4 Min.“.
- Vehicle Positions: der Live-Standort jedes Fahrzeugs, für die Verfolgung auf der Karte.
- Service Alerts: Störungen, Umleitungen und Ausfälle, als Text für den Fahrgast.
Ein häufiger Fehler ist, nur Vehicle Positions (den einfachen Feed) zu veröffentlichen und Trip Updates wegzulassen. Doch Prognosen sind das, was Fahrgäste wirklich wollen: Ein wandernder Punkt ohne Ankunftszeit ist ein Spielzeug, kein Service.
Warum Feeds abgelehnt werden (und wie Sie das vermeiden)
Das häufigste Problem in der Praxis ist nicht die Erzeugung des Feeds, sondern dass die empfangende Plattform (eine regionale Fahrplanauskunft, Google, eine Drittanbieter-App) ihn ablehnt. Fast immer aus denselben Gründen:
- Der Echtzeit-Feed verweist auf Haltestellen- oder Fahrt-IDs, die im statischen GTFS nicht existieren. Beide müssen synchron bleiben: Ändert sich der Fahrplan, werden beide gemeinsam aktualisiert.
- Zeitstempel sind veraltet oder in der falschen Zeitzone, sodass Prognosen eingefroren oder unsinnig wirken.
- Der Feed ist technisch valide, aber die Prognosen sind stark ungenau, und das zerstört Vertrauen schneller als gar keine Daten.
Die Lösung heißt Disziplin: Statischer Fahrplan und Echtzeit-Feed müssen aus derselben Datenquelle stammen. Wenn Netzplanung und Echtzeitbetrieb auf derselben Plattform laufen, geschieht diese Synchronisierung automatisch statt über einen fragilen manuellen Abgleich.
Standards jenseits von GTFS-RT
In Europa existiert GTFS-RT oft neben SIRI (dem europäischen Echtzeitstandard) und neben den Anforderungen nationaler Zugangspunkte und der Aufgabenträger. Ein Netz muss dieselbe Datengrundlage unter Umständen gleichzeitig in mehreren Formaten veröffentlichen. Die praktische Konsequenz: Wählen Sie Werkzeuge, die aus einer einzigen Echtzeit-Engine in alle Standards exportieren, die Ihr Markt verlangt, statt für jedes Format eine eigene Datenstrecke zu pflegen.
Ein Live-Punkt ohne genaue Ankunftszeit ist keine Echtzeitinformation: Er ist Dekoration.
Das Fazit
Bei GTFS-RT in der Praxis geht es weniger um den Standard selbst als darum, Ihr geplantes Angebot und Ihren Live-Betrieb perfekt im Einklang zu halten und dann sauber in alle Kanäle zu exportieren, die Fahrgäste nutzen. Stimmt diese Synchronisierung, ist der Rest Installationsarbeit. Genau deshalb erzeugt Pysae mit dem Modul Operations GTFS-RT- und SIRI-Feeds direkt aus derselben Plattform, die Ihren Betrieb steuert, und ist an Bord ITxPT-kompatibel: eine Datenquelle, jeder Bildschirm automatisch versorgt.
Häufig gestellte Fragen
Welche drei GTFS-RT-Feeds gibt es?
Trip Updates liefert prognostizierte Ankunfts- und Abfahrtszeiten pro Haltestelle, Vehicle Positions den Live-Standort jedes Fahrzeugs und Service Alerts Störungen, Umleitungen und Ausfälle als Text. Die meisten Netze brauchen alle drei, und Trip Updates ist der Feed, den Fahrgäste am meisten schätzen.
Warum lehnt eine Fahrplanauskunft oder Google einen GTFS-RT-Feed ab?
Meist, weil der Echtzeit-Feed auf Haltestellen- oder Fahrt-IDs verweist, die im statischen GTFS nicht existieren. Veraltete Zeitstempel oder eine falsche Zeitzone sind die andere häufige Ursache. Ein Feed kann zudem technisch valide sein und trotzdem stark ungenaue Prognosen liefern, was Vertrauen zerstört.
Wie bleiben statisches GTFS und GTFS-RT synchron?
Beide müssen aus derselben Datenquelle stammen und bei jeder Fahrplanänderung gemeinsam aktualisiert werden. Wenn Netzplanung und Echtzeitbetrieb auf derselben Plattform laufen, geschieht diese Synchronisierung automatisch statt über einen fragilen manuellen Abgleich.
Brauchen europäische Netze neben GTFS-RT auch SIRI?
Häufig ja. In Europa existiert GTFS-RT oft neben SIRI und den Anforderungen nationaler Zugangspunkte und der Aufgabenträger, sodass dieselben Informationen in mehreren Formaten veröffentlicht werden müssen. Pysae erzeugt GTFS-RT- und SIRI-Feeds aus derselben Plattform, die den Betrieb steuert.