El 17 de abril de 2026, la Comunidad de Madrid y el Consorcio Regional de Transportes (CRTM) anunciaron que la posición en tiempo real de los autobuses interurbanos ya se ve en Google Maps, gracias a la conexión de los SAE (Sistema de Ayuda a la Explotación) de los operadores con la aplicación. Para que un autobús aparezca con su tiempo de espera real, el SAE debe entregar un feed continuo y coherente con el horario publicado, y esa coherencia es el verdadero reto técnico.
¿Qué anunció exactamente la Comunidad de Madrid el 17 de abril de 2026?
Según la nota publicada por el CRTM, el consejero de Vivienda, Transportes e Infraestructuras, Jorge Rodrigo, presentó la novedad en la sede del Consorcio con motivo del Día Mundial del Transporte Público. La nota recuerda que los autobuses de la región transportan a más de tres millones de viajeros diarios.
El mecanismo que describe es sencillo de enunciar: se conectan los sistemas tecnológicos de los operadores, es decir, sus SAE, con el planificador de rutas de Google Maps. El viajero elige la opción de transporte público, toca una parada en el mapa y la aplicación muestra las líneas disponibles y el tiempo real de espera de cada una. Según la nota, la información incluye «los tiempos reales de espera, más allá de los horarios previstos».
Conviene leer la nota con precisión. Titula la novedad para los autobuses interurbanos, y su texto indica que los datos ya están operativos en todos los autobuses urbanos e interurbanos de la Comunidad de Madrid. No indica cuántos vehículos, líneas u operadores participan, y no menciona ningún formato de datos concreto. Por eso este artículo no afirma qué formato se utiliza en Madrid: se limita a lo que la nota dice y analiza lo que cualquier consorcio o gran operador debe resolver para llegar a un resultado equivalente.
¿Qué necesita Google para mostrar un autobús en tiempo real?
La documentación de Google para desarrolladores sobre GTFS Realtime explica que se trata de una especificación que permite a las agencias de transporte ofrecer actualizaciones en tiempo real sobre su flota. Es una extensión de GTFS, el formato de horarios y datos geográficos, y se basa en Protocol Buffers. Describe tres tipos de información: actualizaciones de viaje (retrasos, cancelaciones y cambios de ruta), alertas de servicio (paradas movidas y eventos imprevistos) y posiciones de vehículos (ubicación y nivel de congestión).
Sobre las condiciones de publicación, la página de Google indica dos ideas. La primera es que el feed debe estar disponible en una ubicación desde la que Google pueda consultarlo periódicamente. La segunda es que debe actualizarse con regularidad, idealmente cada vez que llegan datos nuevos desde el sistema de localización del operador. La página no fija una frecuencia mínima exacta, de modo que cada red debe definir la suya y vigilarla.
¿Qué contiene un mensaje de posición de vehículo?
La referencia de GTFS.org sobre posiciones de vehículo detalla los elementos principales de cada mensaje:
- El viaje que el vehículo está realizando, indicado mediante un descriptor de viaje.
- El vehículo, con su identificador, su etiqueta y su matrícula.
- La posición, con latitud y longitud obligatorias, y rumbo, odómetro y velocidad como campos opcionales.
- La marca de tiempo en la que se tomó la lectura de posición, distinta de la marca de tiempo del encabezado del feed.
- La parada de referencia del paso actual, que puede indicarse como secuencia de parada o como identificador de parada.
Esa lista muestra por qué un punto GPS no basta. Un punto en el mapa solo se convierte en «el autobús llega en 4 minutos» cuando el sistema sabe qué viaje del horario está haciendo ese vehículo. Si quiere repasar cómo viaja ese dato desde el vehículo hasta la pantalla del viajero, el artículo GTFS-RT en la práctica: del GPS a la pantalla del viajero recorre los tres flujos con más detalle. Aquí interesa un ángulo distinto: qué cambia cuando varios operadores alimentan una misma pantalla.
¿Por qué un consorcio con varios operadores complica la integración?
La nota del CRTM habla de conectar los sistemas de los operadores, en plural. Cada operador puede tener su propio SAE, su propia cadencia de envío y su propia forma de identificar vehículos y servicios. Para el viajero, sin embargo, todo debe verse como una sola red. Esto se traduce en tres exigencias que se desprenden de la documentación de GTFS Realtime.
La primera es una referencia común de viajes. Según la referencia de actualizaciones de viaje, el descriptor de viaje identifica el viaje afectado y normalmente utiliza el identificador del viaje programado en el GTFS estático. En los viajes definidos por frecuencias, ese identificador no es único, así que hay que combinarlo con la hora y la fecha de inicio. Si dos operadores del mismo consorcio resuelven este punto de forma distinta, el viajero verá esperas incoherentes entre líneas vecinas.
La segunda es la completitud. La misma referencia indica que debe haber como máximo una actualización por viaje programado y que, si falta, quien consume el feed no debe asumir que el viaje va puntual. Dicho de otro modo, el silencio de un operador no es neutro: puede interpretarse como ausencia de datos o como puntualidad, según la aplicación. Un consorcio gana mucho cuando sabe, línea por línea, qué viajes llegan al feed y cuáles no.
La tercera es la frescura. Como la propia página de Google pide actualizaciones regulares, un operador cuyo SAE envía con retraso degrada la experiencia de toda la red, no solo la suya. La marca de tiempo de la lectura de posición, distinta de la del feed, es la herramienta para detectar este problema.
¿Qué errores rompen la confianza del viajero?
A partir de lo anterior, los fallos que más se notan en una aplicación de mapas son previsibles:
- Un autobús que aparece en la línea equivocada o con el destino equivocado, porque el vehículo no está asociado al viaje correcto.
- Un viaje cancelado o añadido que no se refleja, de modo que la aplicación sigue mostrando el horario teórico.
- Esperas que saltan hacia atrás o hacia delante porque las posiciones llegan con retraso o fuera de orden.
- Diferencias entre el horario estático publicado y la operación real tras un desvío o un cambio de calendario.
Ninguno de estos fallos es exótico, y todos nacen en el mismo punto: la relación entre lo que el SAE sabe del servicio y lo que el feed cuenta al exterior. El artículo sobre cómo el SAE mantiene cada vehículo emparejado con su servicio correcto se centra en esa base.
¿Qué comprobar antes de publicar en Google Maps?
Una lista de verificación práctica para un operador o un consorcio que quiera ofrecer tiempos reales en aplicaciones de mapas, construida a partir de las fuentes citadas:
- Que los identificadores de viaje del feed en tiempo real coinciden con los del GTFS estático vigente, incluidos los viajes definidos por frecuencias.
- Que cada viaje programado que debe verse en tiempo real tiene su actualización, y que existe una regla clara para los viajes sin datos.
- Que el feed se actualiza con la regularidad que la red haya fijado, y que la marca de tiempo de cada posición permite descartar lecturas antiguas.
- Que las alertas de servicio, como una parada movida o un desvío, se publican en el mismo canal que las posiciones.
- Que alguien en el centro de control revisa periódicamente el resultado desde el lado del viajero, y no solo desde el lado del sistema.
Ninguna de estas comprobaciones depende de la marca del SAE: son propiedades del dato.
¿Cómo encaja Pysae en este flujo?
La página de Pysae Operations lista, entre sus funciones, «Información al viajero y GTFS-RT», con seguimiento del autobús en tiempo real y publicación automática en Google Maps vía GTFS-RT. La misma página incluye «Regulación y supervisión en tiempo real», con «lista de expediciones, adelanto/retraso, desvíos, gestión de relevos en línea», y «Centralización de varias cocheras en un solo puesto del centro de control». En el bloque de datos figuran «Puntualidad, tiempos de recorrido, expediciones realizadas» con exportación CSV y conexión con Power BI.
Por el lado de la planificación, la página de Pysae Network menciona la «Exportación en un clic de archivos GTFS y NeTEx conformes a las exigencias de las AOM» y la gestión de varias redes en un único espacio de trabajo, con permisos de edición delegables por red o por línea. Según esa página, cualquier cambio en Network se propaga al instante a la supervisión en tiempo real de Operations, sin reimportación.
Nada de esto sustituye al trabajo de calidad de datos descrito antes, pero la exportación de GTFS y la publicación automática hacia Google Maps vía GTFS-RT cubren dos pasos de esa cadena.
Si quiere ver cómo se aplica a su red, puede pedir una demo con el botón «Solicitar una demo» que encontrará en la cabecera de la web y al final de este artículo.
Preguntas frecuentes
¿Qué anunció el CRTM sobre Google Maps?
El 17 de abril de 2026, según la nota del Consorcio, la Comunidad de Madrid incorporó por primera vez la posición en tiempo real de los autobuses interurbanos en Google Maps, mediante la conexión de los SAE de los operadores con la aplicación.
¿Qué formato de datos utiliza Madrid?
La nota del CRTM no lo indica. Este artículo describe GTFS Realtime porque es la especificación que documenta Google para este caso, pero no atribuye ese formato a la integración madrileña.
¿Con qué frecuencia debe actualizarse un feed en tiempo real?
La documentación de Google pide que el feed se actualice con regularidad, idealmente cada vez que llegan datos nuevos del sistema de localización, y no fija una frecuencia mínima. Cada red debe definirla y medirla.
¿Basta con tener GPS en los autobuses?
No. La posición solo es útil si el sistema sabe qué viaje del horario está haciendo cada vehículo. El mensaje de posición de GTFS Realtime incluye el viaje, el vehículo, la posición y la marca de tiempo por esa razón.
¿Qué pasa si falta la actualización de un viaje?
Según la referencia de GTFS.org, quien consume el feed no debe asumir que ese viaje va puntual. Por eso conviene controlar qué viajes llegan al feed y cuáles no.