Volver al blog BIM e IFC
Gemelos digitales · 2026-10-16 · 8 min
¿Qué antigüedad tienen los datos urbanos en tiempo real? Seis feeds, medidos durante 24 horas
«Tiempo real» no dice nada de la antigüedad que tienen los datos cuando te llegan. Registramos durante 24 horas seis feeds públicos que leen gemelos digitales en vivo y medimos la antigüedad de cada vehículo y cada estación que contenían. La respuesta va de menos de un segundo a minuto y medio, y la propia marca de tiempo del feed puede ocultarla.
Gemelo digital de la salida de la estación de Tochōmae en IFC Viewer Online: el modelo IFC de la salida A4 sobre el mapa de Tokio, con el número en vivo del tren de Toei que está en el andén flotando encima
Todos los feeds en vivo se presentan como «en tiempo real». En un gemelo digital, esa expresión oculta la única cifra que decide qué significan sus colores: qué antigüedad tienen los datos cuando llegan. Un anclaje de bicicletas pintado de rojo porque hace tres minutos no tenía bicicletas no es lo mismo que uno que no tiene ninguna ahora.
Así que lo medimos. Durante 24 horas registramos seis feeds públicos que leen gemelos en vivo de Barcelona, Helsinki y Tokio, y, para cada vehículo o estación de cada respuesta, comparamos la hora que escribió el proveedor con la hora a la que llegaron los datos. El registro completo está publicado[log].
Lo esencial
- El flujo MQTT de HSL llegó en menos de un segundo. La misma flota en GTFS-Realtime tenía unos 2 segundos de antigüedad, pero los navegadores no pueden leer ese feed.
- Las posiciones de los trenes de Toei tenían alrededor de medio minuto. Las de los autobuses de Toei y las estaciones de Bicing, alrededor de minuto y medio de mediana, y hasta unos tres minutos para el 90 % de ellos.
- La propia marca de tiempo de un feed puede engañar: el archivo de Bicing tenía un tercio de segundo de antigüedad, mientras que las estaciones que contenía habían informado unos 95 segundos antes.
- El feed de cargadores de Endolla no lleva ninguna hora de informe, solo cuándo cambió cada cargador por última vez, así que no hay forma de mostrar si sus datos están al día.
- Las 14 329 peticiones obtuvieron respuesta, y el flujo MQTT transmitió mensajes en cada minuto del día.
Antigüedad mediana de los vehículos o estaciones de una respuesta típica, y hasta dónde llega el 90 % de ellos.
Cómo lo medimos
- Desde las 21:15 UTC del 15 de octubre hasta las 21:15 UTC del 16 de octubre de 2026, en un único ordenador en Europa con el reloj sincronizado.
- El GTFS-Realtime de HSL se consultó cada 15 segundos; Bicing y los dos feeds de Toei, cada 30 segundos; Endolla, cada 5 minutos. Al flujo MQTT de HSL nos suscribimos para la zona de Helsinki, y lo resumimos minuto a minuto.
- En cada respuesta tomamos la mediana y el percentil 90 de sus vehículos o estaciones; el gráfico muestra el valor típico de ambos a lo largo de las 24 horas.
La antigüedad es la hora de llegada menos la marca de tiempo que el proveedor escribió para cada elemento: el momento en que se midió la posición de un vehículo en GTFS-Realtime[gtfsrt], la última vez que una estación informó en GBFS[gbfs], la hora propia de cada mensaje en el flujo de HSL[hfp] y la hora de registro de cada tren en ODPT.
Feed a feed
| Feed | Cómo llega | Antigüedad mediana | El 90 % de los elementos, por debajo de | Elementos por respuesta |
|---|
| Autobuses de HSL, HFP (Helsinki) | MQTT, por push | menos de 1 s | menos de 1 s | ~28 000 mensajes por minuto |
| Vehículos de HSL, GTFS-Realtime (Helsinki) | HTTP, cada 15 s; sin CORS | 1,9 s | 1,9 s | 843 vehículos |
| Trenes de Toei, ODPT (Tokio) | HTTP, cada 30 s | 28 s | 30 s | 92 trenes |
| Autobuses de Toei, GTFS-Realtime (Tokio) | HTTP, cada 30 s | 88 s | 3,1 min | 490 autobuses |
| Estaciones de Bicing, GBFS 3.0 (Barcelona) | HTTP, cada 30 s | 95 s | 2,8 min | 543 estaciones |
| Cargadores de Endolla, GELFS (Barcelona) | HTTP, cada 5 min | no consta | no consta | 1366 conectores |
Valores típicos a lo largo de 24 horas, 15–16 de octubre de 2026. Los recuentos de elementos son medianas; Toei no tiene trenes ni autobuses en circulación de madrugada.Salen tres grupos. HSL publica lo que dice cada autobús en el momento en que lo dice, así que la antigüedad es casi cero por MQTT y de unos dos segundos en su archivo GTFS-Realtime, que se genera por lotes. Los registros de trenes de Toei solían tener alrededor de medio minuto. Los autobuses de Toei y las estaciones de Bicing informan cada pocos minutos, así que en cualquier momento alrededor de la mitad supera el minuto y medio: el 49 % de los autobuses y el 52 % de las estaciones tenían más de 90 segundos de antigüedad.
La marca de tiempo que dice «reciente»
El archivo de estado de las estaciones de Bicing lleva una hora last_updated, y siempre estaba a menos de un segundo de la hora actual: el archivo recibe la marca en el momento en que se sirve. Las 543 estaciones que contiene habían informado, en mediana, 95 segundos antes. Un gemelo que se fiara de la hora del archivo mostraría «actualizado hace 0 s» sobre datos de hace minuto y medio. El feed de autobuses de Toei muestra el mismo patrón, más suave: la marca de tiempo del archivo tenía unos 16 segundos; sus autobuses, unos 88.
La lección es sencilla: la antigüedad es una propiedad de cada elemento, no del archivo. Lee la hora que comunica cada vehículo o estación, y muestra esa.
El feed que no puede decirlo
El tamaño del archivo de puntos de recarga de Endolla cambió en 262 de 286 intervalos de cinco minutos, así que es evidente que se mantiene. Pero cada conector solo lleva la hora en que cambió su estado por última vez: la mitad no había cambiado en unas 21 horas, y una décima parte, en más de 10 días. Puede ser perfectamente exacto (un cargador que nadie usó durante la noche) o puede ser un cargador que dejó de informar; el feed no permite distinguir un caso del otro. Un gemelo puede mostrar esos datos «tal como se publican», nunca como datos en vivo.
Push frente a consulta periódica
Los dos canales de HSL transportan los mismos autobuses. Por MQTT, cada posición llega en cuanto se produce; en el archivo que se consulta periódicamente, espera al siguiente lote, y el navegador, además, espera a su siguiente consulta. Consultar también tiene un coste: el archivo de Bicing ocupa unos 268 KB sin comprimir con las 543 estaciones, así que un gemelo que necesita una sola estación las descarga todas en cada consulta. Consultar más deprisa de lo que cambia la fuente solo sirve para gastar ese ancho de banda dos veces.
Qué significa para un gemelo
- Muestra la antigüedad junto al valor, calculada con la marca de tiempo del propio elemento, no con la del archivo.
- Fija el límite de antigüedad por encima de la antigüedad normal del feed. Los ejemplos en vivo de este blog usan 45 segundos para las dársenas de autobús de HSL, 2 minutos para los trenes de Toei, 10 minutos para la parada de autobús de Toei y 15 minutos para Bicing.
- El gris significa «sin datos recientes», nunca el último valor disfrazado de actual.
- Prefiere el push cuando el proveedor lo ofrece; no consultes más deprisa de lo que cambia la fuente.
- Un feed sin hora por elemento se puede mostrar, pero no presentar como datos en vivo.
La otra mitad de la pregunta es si una página web puede leer siquiera cada uno de estos feeds: qué datos abiertos de una ciudad puede leer una página web. Cómo usa el gemelo de Helsinki el flujo MQTT se explica en el gemelo de la terminal de autobuses con MQTT.
¿Qué antigüedad tienen los datos urbanos en tiempo real? Seis feeds, medidos durante 24 horas