A los viajeros no les importa tu arquitectura de datos. Les importa una sola cosa: ¿viene el autobús de verdad, y cuándo? GTFS-RT (la extensión en tiempo real del estándar GTFS) es lo que convierte la posición GPS de tus autobuses en esa respuesta — en la app, en la pantalla de la parada, en Google Maps. Pero entre el vehículo en la carretera y la pantalla del viajero, muchas cosas deben ocurrir correctamente. Así funciona en la práctica, y dónde suele fallar.
Del ping GPS a la pantalla del viajero
Cada autobús equipado con Pysae envía su posición con regularidad — normalmente cada 30 segundos. Esa posición en bruto no es más que un punto en un mapa. Para convertirse en información útil en tiempo real, debe asociarse al servicio planificado: qué línea, qué expedición, qué parada viene a continuación y cómo se compara con el horario. Ese paso de asociación es donde reside la inteligencia. Una posición sin contexto no le dice nada al viajero; una posición ligada a «Línea 3, 4 minutos de retraso, llega a tu parada en 6 minutos» cambia toda su experiencia.
Los tres tipos de flujo GTFS-RT
GTFS-RT no es una sola cosa — son tres flujos relacionados, y la mayoría de las redes necesitan los tres:
- Trip Updates: horas de llegada y salida previstas por parada. Es lo que alimenta el «próximo bus en 4 min».
- Vehicle Positions: la ubicación en vivo de cada vehículo, para el seguimiento en el mapa.
- Service Alerts: incidencias, desvíos y cancelaciones, en un texto que el viajero lee.
Un error frecuente es publicar solo Vehicle Positions (el fácil) y omitir Trip Updates. Pero las predicciones son lo que los viajeros realmente quieren — un punto en movimiento sin hora de llegada es un juguete, no un servicio.
Por qué se rechazan los flujos (y cómo evitarlo)
El problema más frecuente en la práctica no es generar el flujo, sino que la plataforma receptora (un planificador de viajes regional, Google, una app de terceros) lo rechace. Casi siempre por las mismas razones:
- El flujo en tiempo real hace referencia a IDs de parada o de expedición que no existen en el GTFS estático. Ambos deben mantenerse sincronizados — cuando cambia el horario, los dos se actualizan a la vez.
- Las marcas de tiempo están obsoletas o en la zona horaria equivocada, así que las predicciones parecen congeladas o sin sentido.
- El flujo se valida técnicamente pero las predicciones son tremendamente inexactas, lo que erosiona la confianza más rápido que la ausencia de datos.
La solución es disciplina: el plan estático y el flujo en tiempo real deben proceder de la misma fuente de verdad. Cuando la planificación de la red y las operaciones en tiempo real viven en la misma plataforma, esta sincronización es automática en lugar de una frágil reconciliación manual.
Estándares más allá de GTFS-RT
En Europa, GTFS-RT a menudo convive con SIRI (el estándar europeo en tiempo real) y, en Francia, con los requisitos regionales de la AOM. Una red puede necesitar publicar la misma verdad subyacente en varios formatos a la vez. La implicación práctica: elige herramientas que exporten a todos los estándares que exige tu mercado desde un único motor en tiempo real, en lugar de mantener un proceso distinto por formato.
Un punto en vivo sin una hora de llegada precisa no es información en tiempo real
En resumen
GTFS-RT en la práctica tiene menos que ver con el estándar en sí y más con mantener tu servicio planificado y tus operaciones en vivo perfectamente alineados, y luego exportar de forma limpia a todos los canales que usan los viajeros. Si aciertas con esa sincronización, lo demás es fontanería. Por eso precisamente Pysae genera los flujos GTFS-RT, SIRI e ITxPT directamente desde la misma plataforma que gestiona tus operaciones — una sola fuente de verdad, cada pantalla alimentada automáticamente.