4.5 GTFS para Google Transit

Con Google Transit, los usuarios pueden ver las opciones de transporte público en Google Maps y planificar rutas para llegar a su destino. Al compartir los datos de rutas y horarios, la información del servicio queda disponible para millones de personas en decenas de idiomas, tanto en computadoras como en dispositivos móviles.

Participar en Google Transit tiene varias ventajas para una agencia u organismo de transporte:

• Mayor alcance — Google Transit funciona junto al planificador de trayectos propio, y dirige a los usuarios, tanto nuevos pasajeros como habituales, al sitio web de la agencia para que descubran los servicios disponibles.
• Cobertura multilingüe — Google Maps permite planificar trayectos en el idioma del usuario sin que este tenga que aprender un sistema nuevo.
• Sin costo — Cualquier operador con rutas fijas y horarios programados puede participar. Solo hay que facilitar los datos.

Cuando se comparte la información estática de rutas, paradas y horarios, Google la incorpora a Google Maps y queda disponible para todos sus usuarios. Más información sobre Google Transit

Un feed GTFS válido según el estándar puede no ser suficiente para aparecer en Google Maps. Google Transit tiene sus propios requisitos sobre qué archivos y campos procesa, qué extensiones acepta y cómo se gestionan los feeds dentro de su plataforma. Esta sección cubre lo que hay que saber para que un feed llegue a Google Maps y funcione correctamente.

La referencia completa de Google sobre diferencias con el estándar está en la documentación oficial. developers.google.com/transit

Qué procesa Google y qué ignora

Google Transit no implementa la totalidad del estándar GTFS. Algunos archivos y campos son completamente ignorados, aunque el feed los incluya y sean válidos según el validador oficial.

Archivos ignorados

Los siguientes archivos no son procesados por Google Transit aunque estén bien formados:

• areas.txt
• fare_leg_rules.txt
• fare_products.txt
• levels.txt
• stop_areas.txt

Incluirlos no causa errores, pero su contenido no tiene efecto en Google Maps.

Campos con comportamiento diferente

transfers en fare_attributes.txt — El estándar GTFS define los valores válidos como 0, 1 o 2. Google acepta valores de 0 a 5 para especificar el número máximo de transbordos permitidos con esa tarifa.

transfer_type en transfers.txt — Google solo procesa los valores 0 al 3. Los valores 4 y 5, válidos en el estándar, son ignorados.

Formato de horas en stop_times.txt — El estándar permite horas superiores a 23 para representar viajes que cruzan medianoche (por ejemplo, 25:30:00 para la 1:30 a.m. del día siguiente). Google acepta valores de 00 a 99 en el campo de horas.

Lo que sí es obligatorio

Los siete archivos base del estándar siguen siendo obligatorios sin excepción:

• agency.txt
• routes.txt
• trips.txt
• stops.txt
• stop_times.txt
• calendar.txt o calendar_dates.txt

Un feed que pase el validador oficial con cero errores y que incluya estos archivos correctamente formados cumple los requisitos técnicos mínimos.

Extensiones de Google

Google ha añadido campos propietarios al estándar para cubrir casos de uso específicos de su plataforma. Estos campos son opcionales y no son reconocidos por el validador estándar de MobilityData — son una extensión exclusiva de Google.

trip_direction_name en trips.txt — Nombre legible por el usuario para indicar la dirección del viaje, diferente al trip_headsign. Por ejemplo: “Hacia el centro” o “Hacia la terminal norte”. Aparece en la interfaz de Google Maps al mostrar opciones de ruta.

stop_direction_name en stops.txt — Texto que indica la dirección del servicio en una parada específica. Útil cuando el mismo punto físico tiene paradas en sentidos opuestos.

exceptional en trips.txt — Marca un viaje como excepcional (valor 1) cuando opera solo bajo condiciones especiales como eventos o días festivos. Google puede usar este dato para gestionar cómo muestra el servicio en esas fechas.

Amenidades del vehículo — Google soporta campos para indicar características del vehículo como presencia de WiFi o aire acondicionado. Estos campos forman parte de las extensiones experimentales y su disponibilidad para nuevos operadores requiere coordinación directa con el equipo de Google Transit.

Proceso de envío al Transit Data Sharing Portal

Google gestiona los feeds de tránsito a través del Transit Data Sharing Portal, accesible desde el centro de ayuda para socios. support.google.com/transitpartners

El proceso tiene las siguientes etapas:

1. Solicitar acceso al portal

El acceso al portal no es automático — requiere registrarse como socio de Google Transit a través del formulario oficial. Solicitar acceso como agencia

El formulario pide información básica sobre la organización: nombre de la agencia, país, ciudad o región cubierta, y datos de contacto. Una vez enviada la solicitud, el equipo de Google Transit la revisa y, si es aprobada, otorga acceso al portal con una cuenta de Google designada.

Es importante que la cuenta de Google con la que se gestione el portal sea una cuenta institucional o que esté bajo control de la organización — no una cuenta personal. Esta cuenta será la que tenga acceso a la vista previa privada del feed en Google Maps y recibirá las comunicaciones del equipo de Google durante la revisión de calidad.

2. Subir el feed y pasar la validación del portal

Una vez con acceso, el feed se sube a través de la sección Pipelines → Static. El portal ejecuta su propio validador, que es más estricto que el validador abierto de MobilityData. Los errores deben resolverse todos antes de continuar; algunas advertencias también pueden ser bloqueantes.

3. Activar la vista previa privada

Cuando el feed pasa la validación, se puede activar una vista previa privada. En esta etapa, los datos son visibles en Google Maps únicamente para la cuenta de Google asociada al portal, no para el público general. Es el momento de verificar que rutas, paradas y horarios aparezcan correctamente antes del lanzamiento.

Se recomienda que las pruebas las realicen personas que conozcan bien el servicio de transporte — representantes de atención al usuario, operadores, técnicos del municipio — ya que pueden detectar inconsistencias que un revisor externo pasaría por alto.

Acceder a la vista previa

Para ver los datos en Google Maps:

1. Iniciar sesión en Google Maps con la cuenta de Google asociada al portal de Transit Partners.
2. Buscar rutas de tránsito en la zona de servicio.
3. Probar distintos tipos de consulta: ubicaciones de paradas, horarios de salida y llegada, trazos de ruta.

Los resultados de rutas en modo vista previa aparecen sobre un fondo rosa claro — esa es la señal visual de que se está viendo el feed de staging y no el feed público.

Si varias personas necesitan acceder a la vista previa, se puede crear una cuenta genérica de Gmail (por ejemplo, agencia.transit@gmail.com) para compartirla, o asociar la cuenta del portal a un alias de correo institucional.

Consultas aleatorias de prueba

La pestaña Consultas del reporte de validación del portal genera un listado de viajes de ejemplo basados en los datos del feed. Es el punto de partida más práctico para una primera revisión.

Planificación manual de viajes

Para una revisión más completa, conviene planificar viajes manualmente usando coordenadas de paradas reales:

1. Abrir Google Maps y seleccionar Cómo llegar → Transporte público.
2. Ingresar coordenadas de latitud y longitud de las paradas como origen y destino.
3. Probar tanto la opción Salir ahora como Salir a las para verificar distintos horarios.

En la vista previa no están disponibles los nombres de paradas — hay que navegar con coordenadas. Tampoco se muestran conexiones con otros operadores.

Qué verificar en cada viaje planificado

Después de planificar un viaje, revisar que los siguientes datos sean correctos y coincidan con la información publicada en el sitio web oficial del servicio:

• Nombre corto y largo de la ruta
• Horarios de cada parada (fecha y hora)
• Nombre de las paradas
• Duración total del trayecto
• Trazo geográfico de la ruta (shapes)
• Nombre, URL y teléfono de la agencia
• Información de tarifa y URL de tarifas (si se incluyeron en el feed)

Lista de verificación del feed

Antes de solicitar la revisión de calidad, conviene repasar estos puntos:

Cobertura y fechas

• El período de servicio cubre más de 28 días y menos de 3 años.
• Las fechas de calendar.txt están vigentes y cubren al menos los próximos 7 días.
• Las excepciones en calendar_dates.txt coinciden con el período definido en calendar.txt e incluyen todos los días festivos o servicios especiales.

agency.txt

• El nombre, URL, teléfono y zona horaria de la agencia son correctos y coinciden con el sitio web.

routes.txt

• Los nombres y colores de las rutas coinciden con los del sitio web oficial y son reconocibles para los usuarios.
• Si se definen tanto route_short_name como route_long_name, el que ven los usuarios es el nombre corto.
• Las rutas no están divididas por dirección — ida y vuelta van en la misma ruta.

trips.txt

• Los trip_headsign indican la dirección del viaje de forma reconocible y no repiten el nombre de la ruta.
• trip_short_name solo se usa para trenes interurbanos o de larga distancia.

stops.txt

• Los nombres de paradas son claros, consistentes y no incluyen códigos de parada.
• Las ubicaciones están en el lado correcto de la calzada y cerca de la acera.
• Si se definen stop_code, deben coincidir con los códigos publicados en el sitio web.

shapes.txt (opcional pero muy recomendable)

• Los trazos siguen con precisión las vías.
• Todos los viajes tienen un shape_id asignado en trips.txt.
• No hay advertencias de validación relacionadas con shapes.

stop_times.txt

• Los horarios coinciden con los publicados en el sitio web del servicio.
• En rutas circulares, se define stop_headsign en cada parada.

Advertencias de validación a resolver antes del QA

• Paradas demasiado lejos del shape.
• Paradas que no coinciden con el shape en el orden correcto.
• Demasiadas paradas consecutivas con la misma hora.
• Paradas de distintos viajes que se solapan en la misma manzana.
• Fechas de servicio faltantes.

4. Solicitar la revisión de calidad

Una vez confirmada la vista previa, se solicita al equipo de Google una revisión de calidad (QA). La revisión la realiza un técnico de Google que puede estar ubicado en otra región del mundo. Si durante la revisión se detectan problemas y se abre un issue, la comunicación puede demorarse varios días por el desfase horario y los tiempos de respuesta internos.

Esta revisión es especialmente exhaustiva la primera vez que se publica un feed. Google verifica la coherencia del servicio, la calidad geográfica de los datos y que la información sea útil para los usuarios. También confirma que los horarios y tarifas del servicio estén publicados en un sitio web oficial de la agencia u organismo operador — es un requisito para acreditar que la información del feed es pública y oficial. El sitio no necesita incluir un mapa, aunque tenerlo facilita la consulta para los ciudadanos.

Un ejemplo de este tipo de sitio es el portal de transporte de Zamora. rutaton.zamora.gob.mx.

En subidas posteriores, si el feed no tiene cambios drásticos respecto a la versión anterior, la verificación es casi automática y requiere mucha menos intervención humana.

5. Configurar la entrega periódica

Cuando el feed está aprobado, se configura el método de entrega: una URL pública del archivo ZIP que Google consultará periódicamente para mantener los datos actualizados, o una subida manual recurrente. La opción de URL es la más práctica para mantener el feed al día.

6. Publicar en Google Maps

Una vez configurada la entrega, el feed se lanza al público. El procesamiento toma entre 24 y 48 horas; lo recomendable es planear el envío con al menos una semana de anticipación para absorber cualquier problema que requiera revisión humana.

Cobertura temporal del feed

Google requiere que el feed esté vigente para al menos los próximos 7 días desde la fecha en que está disponible. En la práctica, lo recomendable es cubrir varias semanas o el período completo del calendario de servicio actual. Un feed con fechas vencidas en calendar.txt puede ser rechazado o no mostrarse correctamente.

Verificación en Google Maps

Una vez publicado, la verificación se hace directamente en Google Maps buscando rutas de tránsito en la zona de servicio.

Qué revisar:

• Paradas — Que aparezcan en las ubicaciones correctas y con los nombres del feed.
• Rutas — Que el trazo geográfico siga el recorrido real y no haya saltos o desvíos.
• Horarios — Que los tiempos mostrados correspondan a los definidos en stop_times.txt.
• Dirección del servicio — Que la dirección de cada viaje sea reconocible para el usuario (especialmente si se usó trip_direction_name).
• Correspondencia con realidad — Contrastar con el servicio real: que las paradas existan físicamente en el lugar indicado.

Si algo no aparece correctamente después de las 48 horas de procesamiento, el primer paso es revisar el reporte de validación en el portal y verificar que no haya advertencias bloqueantes que hayan quedado sin resolver.