Zurück zum BIM- & IFC-Blog
Digitale Zwillinge · 2026-10-16 · 8 Min.
Wie aktuell sind städtische Echtzeitdaten? Sechs Feeds, 24 Stunden lang gemessen
„Echtzeit“ sagt nichts darüber, wie alt die Daten sind, wenn sie bei Ihnen ankommen. Wir haben sechs öffentliche Feeds, die digitale Zwillinge live lesen, 24 Stunden lang protokolliert und das Alter jedes Fahrzeugs und jeder Station darin gemessen. Die Antwort reicht von unter einer Sekunde bis zu anderthalb Minuten, und der eigene Zeitstempel des Feeds kann das verschleiern.
Digitaler Zwilling eines Ausgangs der Station Tochōmae im IFC Viewer Online: das IFC-Modell von Ausgang A4 auf der Karte von Tokio, darüber schwebend die Live-Nummer des Toei-Zuges am Bahnsteig
Jeder Live-Feed nennt sich Echtzeit. Für einen digitalen Zwilling verdeckt dieses Wort genau die eine Zahl, die bestimmt, was seine Farben bedeuten: wie alt die Daten sind, wenn sie ankommen. Ein Fahrrad-Dock, das rot eingefärbt ist, weil dort vor drei Minuten keine Räder standen, ist nicht dasselbe wie eines, an dem jetzt keine stehen.
Also haben wir gemessen. 24 Stunden lang haben wir sechs öffentliche Feeds protokolliert, die Live-Zwillinge in Barcelona, Helsinki und Tokio lesen, und für jedes Fahrzeug und jede Station in jeder Antwort die Zeit, die der Herausgeber eingetragen hatte, mit der Ankunftszeit der Daten verglichen. Das vollständige Protokoll ist veröffentlicht[log].
Das Wichtigste
- Der MQTT-Stream von HSL kam in unter einer Sekunde an. Dieselbe Flotte war als GTFS-Realtime etwa 2 Sekunden alt, doch diesen Feed können Browser nicht lesen.
- Die Zugpositionen von Toei waren etwa eine halbe Minute alt. Die Buspositionen von Toei und die Bicing-Stationen waren im Median etwa anderthalb Minuten alt, bei 90 % von ihnen bis zu etwa drei Minuten.
- Der eigene Zeitstempel eines Feeds kann täuschen: Die Datei von Bicing war eine Drittelsekunde alt, während die Stationen darin etwa 95 Sekunden zuvor gemeldet hatten.
- Der Ladepunkt-Feed von Endolla enthält überhaupt keine Meldezeit, nur den Zeitpunkt der letzten Änderung jedes Ladepunkts. Wie aktuell er ist, lässt sich daher nicht zeigen.
- Alle 14.329 Anfragen wurden beantwortet, und der MQTT-Stream lieferte in jeder Minute des Tages Nachrichten.
Medianalter der Fahrzeuge oder Stationen in einer typischen Antwort und der Bereich, in dem 90 % von ihnen liegen.
So haben wir gemessen
- Vom 15. Oktober, 21:15 UTC, bis zum 16. Oktober 2026, 21:15 UTC, auf einem Rechner in Europa mit synchronisierter Uhr.
- HSL GTFS-Realtime wurde alle 15 Sekunden abgefragt, Bicing und beide Toei-Feeds alle 30 Sekunden, Endolla alle 5 Minuten. Den MQTT-Stream von HSL haben wir für den Raum Helsinki abonniert und pro Minute zusammengefasst.
- Für jede Antwort haben wir Median und 90. Perzentil über ihre Fahrzeuge oder Stationen bestimmt; die Grafik zeigt den typischen Wert dieser Kennzahlen über die 24 Stunden.
Das Alter ist die Ankunftszeit abzüglich des Zeitstempels, den der Herausgeber für jeden Eintrag geschrieben hat: bei GTFS-Realtime[gtfsrt] der Zeitpunkt, zu dem die Position eines Fahrzeugs gemessen wurde, bei GBFS[gbfs] die letzte Meldung einer Station, im Stream von HSL[hfp] die eigene Zeit jeder Nachricht und bei ODPT die Datensatzzeit jedes Zuges.
Feed für Feed
| Feed | Übertragung | Medianalter | 90 % der Einträge unter | Einträge pro Antwort |
|---|
| HSL-Busse, HFP (Helsinki) | MQTT, Push | unter 1 s | unter 1 s | ~28.000 Nachrichten pro Minute |
| HSL-Fahrzeuge, GTFS-Realtime (Helsinki) | HTTP, alle 15 s; kein CORS | 1,9 s | 1,9 s | 843 Fahrzeuge |
| Toei-Züge, ODPT (Tokio) | HTTP, alle 30 s | 28 s | 30 s | 92 Züge |
| Toei-Busse, GTFS-Realtime (Tokio) | HTTP, alle 30 s | 88 s | 3,1 min | 490 Busse |
| Bicing-Stationen, GBFS 3.0 (Barcelona) | HTTP, alle 30 s | 95 s | 2,8 min | 543 Stationen |
| Endolla-Ladepunkte, GELFS (Barcelona) | HTTP, alle 5 min | nicht angegeben | nicht angegeben | 1.366 Anschlüsse |
Typische Werte über 24 Stunden, 15.–16. Oktober 2026. Die Anzahl der Einträge ist jeweils der Median; in den frühen Morgenstunden fahren bei Toei weder Züge noch Busse.
Es zeigen sich drei Gruppen. HSL veröffentlicht, was jeder Bus meldet, im selben Moment, in dem er es meldet; über MQTT liegt das Alter daher nahe null und in der gebündelten GTFS-Realtime-Datei bei etwa zwei Sekunden. Die Zugdatensätze von Toei waren typischerweise etwa eine halbe Minute alt. Die Busse von Toei und die Stationen von Bicing melden jeweils nur alle paar Minuten, sodass zu jedem Zeitpunkt etwa die Hälfte von ihnen älter als anderthalb Minuten ist: 49 % der Busse und 52 % der Stationen waren älter als 90 Sekunden.
Der Zeitstempel, der „aktuell“ sagt
Die Stationsstatus-Datei von Bicing trägt eine last_updated-Zeit, und diese war nie mehr als eine Sekunde alt: Die Datei erhält ihren Zeitstempel erst beim Ausliefern. Die 543 Stationen darin hatten im Median 95 Sekunden früher gemeldet. Ein Zwilling, der der Zeit der Datei vertraut, würde „vor 0 s aktualisiert“ über Daten anzeigen, die anderthalb Minuten alt sind. Der Bus-Feed von Toei zeigt dasselbe Muster in schwächerer Form: Der Zeitstempel der Datei war etwa 16 Sekunden alt, ihre Busse etwa 88.
Die Lehre daraus ist einfach: Das Alter ist eine Eigenschaft jedes einzelnen Eintrags, nicht der Datei. Lesen Sie die Zeit, die jedes Fahrzeug und jede Station meldet, und zeigen Sie diese an.
Der Feed, der es nicht sagen kann
Die Größe der Ladepunkt-Datei von Endolla änderte sich in 262 von 286 Fünf-Minuten-Intervallen, sie wird also eindeutig gepflegt. Doch jeder Anschluss trägt nur den Zeitpunkt, zu dem sich sein Zustand zuletzt geändert hat: Bei der Hälfte war das seit etwa 21 Stunden nicht mehr geschehen, bei einem Zehntel seit mehr als 10 Tagen. Das kann völlig zutreffen – ein Ladepunkt, den über Nacht niemand genutzt hat –, ebenso gut aber ein Ladepunkt sein, der nicht mehr meldet; der Feed kann das eine nicht vom anderen unterscheiden. Ein Zwilling kann solche Daten als „wie veröffentlicht“ zeigen, aber nie als live.
Push oder Polling
Die beiden Kanäle von HSL übertragen dieselben Busse. Über MQTT kommt jede Position an, sobald sie entsteht; in der abgefragten Datei wartet sie auf den nächsten Stapel, und der Browser wartet zusätzlich auf seine nächste Abfrage. Polling kostet außerdem: Die Bicing-Datei umfasst für alle 543 Stationen vor der Komprimierung etwa 268 KB, ein Zwilling, der eine einzige Station braucht, lädt also bei jeder Abfrage trotzdem alle herunter. Häufiger abzufragen, als sich die Quelle ändert, verbraucht diese Bandbreite nur doppelt.
Was das für einen Zwilling bedeutet
- Zeigen Sie das Alter neben dem Wert an, berechnet aus dem Zeitstempel des Eintrags selbst, nicht aus dem der Datei.
- Legen Sie die Grenze, ab der Daten als veraltet gelten, oberhalb des normalen Alters des Feeds fest. Die Live-Beispiele hier verwenden 45 Sekunden für die HSL-Bussteige, 2 Minuten für Toei-Züge, 10 Minuten für die Toei-Bushaltestelle und 15 Minuten für Bicing.
- Grau heißt „keine aktuellen Daten“ – nie der letzte Wert, der sich als aktuell ausgibt.
- Nutzen Sie Push, wo der Herausgeber es anbietet; fragen Sie nicht häufiger ab, als sich die Quelle ändert.
- Ein Feed ohne Zeitangabe pro Eintrag kann angezeigt, aber nicht als live bezeichnet werden.
Ob eine Webseite jeden dieser Feeds überhaupt lesen darf, ist die andere Hälfte der Frage: welche offenen Stadtdaten eine Webseite lesen kann. Wie der Helsinki-Zwilling den MQTT-Stream nutzt, zeigt der Busbahnhof-Zwilling über MQTT.
Quellen
- Das 24-Stunden-Protokoll als CSV — IFC Viewer Online. Jede Abfrage jedes Feeds (und jede Minute des MQTT-Streams) mit der Altersverteilung der enthaltenen Fahrzeuge oder Stationen. 15.–16. Oktober 2026.
- GTFS-Realtime-Referenz — MobilityData. VehiclePosition.timestamp: der Zeitpunkt, zu dem die Position des Fahrzeugs gemessen wurde.
- General Bikeshare Feed Specification — MobilityData. last_reported: der Zeitpunkt, zu dem eine Station ihren Status zuletzt an das Backend des Betreibers gemeldet hat.
- Hochfrequente Positionierung (HFP) — Digitransit / HSL. Die Fahrzeugpositionen von HSL über MQTT, mit einem Zeitstempel pro Nachricht.
Wie aktuell sind städtische Echtzeitdaten? Sechs Feeds, 24 Stunden lang gemessen