Requisitos de GTFS

El socio debe proporcionar un feed de GTFS que cumpla con todas las especificaciones estándar, además de las que se indican a continuación. Este feed debe incluir todos los itinerarios que el socio quiera mostrar. Proporcionar esta información permitirá que se muestre la información de horarios y rutas en Google. Ten en cuenta que un socio puede optar por exponer información adicional sobre precios y disponibilidad para algunos o todos los itinerarios del feed proporcionado si así lo desea.

Requisitos predeterminados

Referencia de GTFS Static: Se aplican todos los requisitos predeterminados.

Prácticas recomendadas de GTFS: Sigue las prácticas recomendadas como si fueran obligatorias.

Cómo subir feeds GTFS: Sigue este proceso para subir el feed GTFS.

Actualizaciones: Ten en cuenta que, una vez que se suban los feeds, se pueden actualizar siguiendo el proceso que se describe aquí. En general, estas actualizaciones de feeds pueden tardar entre 2 y 3 días en propagarse por completo.

Requisitos adicionales

Alcance

• Un solo feed de GTFS debe abarcar un solo país o una parte de un país. Los viajes que cruzan fronteras nacionales deben proporcionarse en feeds separados para todo el continente. Si un feed de GTFS abarca un área más grande que un país, comunícate con el equipo de transporte de Viajes.
  • Los archivos dentro del archivo ZIP de GTFS deben tener un tamaño inferior a 4 GB. Los archivos más grandes que este suelen ser un signo de malas prácticas, como ignorar las opciones de compresión que ofrece frequencies.txt o funciones similares. Esto puede causar problemas durante el procesamiento. Si crees que necesitas archivos de más de 4 GB, comunícate con el equipo de Transporte de Viajes a [e-mail].
  • Con cada actualización de los datos de GTFS, se deben proporcionar los datos de todo el período futuro de operación de los servicios dentro de un feed de GTFS. No se acepta la segmentación de los servicios por diferentes períodos.
• Todas las fechas de un operador determinado deben estar incluidas en un solo feed.

Traducciones

• Las traducciones se pueden proporcionar con translations.txt y serán obligatorias en los países donde se cumpla alguna de las siguientes condiciones:
  • La información para los usuarios se puede proporcionar en diferentes alfabetos o en alfabetos distintos del latino.
  • La información para los usuarios se puede proporcionar en varios idiomas o cuando las entidades pueden usar nombres diferentes en esos idiomas (p. ej., Bruselas/Brussel/Bruxelles).
• Entidades que se deben traducir
  • Nombres de agencias, paradas y rutas
  • Carteles de paradas y viajes

Nombres de rutas, nombres cortos de viajes y señales de destino

• Se deben proporcionar señales de destino para todos los viajes, ya sea en trips.txt (si la señal de destino permanece constante durante todo el viaje) o en stop_times.txt (si la señal de destino cambia durante las diferentes etapas del viaje).
• Los indicadores de parada deben coincidir con la información que los usuarios pueden encontrar en el suelo. Por ejemplo, las señales de destino que se muestran en el vehículo o en los carteles.
• Cuando una ruta tiene un nombre, se debe proporcionar como long_name en routes.txt.
• Cuando una ruta tiene un número o un identificador alfanumérico específico que se aplica a todos los viajes de esa ruta y en ambas direcciones, se debe proporcionar como short_name en routes.txt.
• Cuando los viajes dentro de la ruta tienen identificadores individuales (por ejemplo, números de tren), estos identificadores deben proporcionarse como nombres cortos de viaje.
• Para los servicios de larga distancia que no tienen números ni nombres de ruta, elegir un nombre de ruta se vuelve problemático. En estas situaciones, la regla general es que una combinación del nombre de la ruta y el letrero de destino debería ayudar al usuario a identificar el vehículo de forma inequívoca. Por ejemplo, el nombre de la empresa operadora se puede usar como nombre de la ruta, mientras que el destino del viaje (si se muestra en el vehículo) se debe usar como señal de destino del viaje.

Ejemplos

• Tren Kamayani Express de Indian Railways 11071 de Mumbai a Varanasi. Nota: El número 11071 identifica un viaje en tren específico de Mumbai a Varanasi, no la ruta en sí.
  • routes.txt:
    • short_name: <empty>
    • long_name: Kamayani Express
  • trips.txt:
    • trip_short_name: 11071
    • headsign: Varanasi
• Un autobús de Buenos Aires a Córdoba operado por Chevallier Bus. Nota: El autobús que operaba este servicio no muestra un nombre de ruta en particular. En cambio, muestra de forma destacada el nombre de la agencia operadora y su destino. Este viaje específico no tiene un número o identificador individual que lo distinga de otros viajes operados por la misma agencia o que sirven la misma ruta. En ese caso, se puede usar "Chevallier" como nombre de la agencia (en agencies.txt) y como nombre largo de la ruta (en routes.txt). El destino se debe usar para el letrero de destino. El campo trip_short_name debe permanecer vacío.
  • routes.txt:
    • short_name: <empty>
    • long_name: Chevallier
  • trips.txt:
    • trip_short_name: <empty>
    • headsign: Córdoba

Horarios de parada

Se deben proporcionar arrival_time y departure_time en stop_times.txt.

Estructura del viaje

• Los viajes de larga distancia que abarcan varias ciudades o áreas deben proporcionarse de extremo a extremo sin segmentación (p.ej., A->B->C, no [A->B, A->C, B->C]), donde A, B y C son áreas de la ciudad. Por ejemplo, un autobús de larga distancia que viaja de Buenos Aires a Córdoba, con una parada en Rosario, debe representarse como un viaje con paradas en estas tres ciudades, no como tres viajes “Buenos Aires - Rosario”, “Buenos Aires - Córdoba” y “Rosario - Córdoba”.
• En los casos en que el proveedor de datos no pueda obtener la información sobre la estructura correcta del viaje, es posible que se proporcionen viajes segmentados de ciudad a ciudad según cada caso. Si estos viajes de ciudad a ciudad tienen varios puntos de partida o de destino dentro de una ciudad (área de la ciudad), no se permite la segmentación de parada a parada. Todos los puntos de partida y todos los puntos de destino deben aparecer en un solo viaje.

Estructuras de estaciones

En el caso de las estaciones grandes que tienen varias plataformas o dársenas, las relaciones entre la estación y la plataforma se deben especificar en el feed, y las dársenas o plataformas específicas se deben identificar a través del campo platform_code en stops.txt. Los vehículos que salen de una plataforma o dársena específica, o llegan a ella, de forma constante deben vincularse a esa plataforma o dársena en el feed de GTFS. Si la plataforma o la dársena de salida o llegada cambian en diferentes días u horas de salida, esta información se puede proporcionar en GTFS en tiempo real.

Ubicaciones de estaciones o paradas

• En el caso de las estaciones grandes que tienen varias plataformas o dársenas, la ubicación de la estación debe establecerse en la ubicación de su entrada peatonal más destacada (si la estación tiene un edificio o una estructura) o en la ubicación del área de espera de pasajeros (para las estaciones al aire libre).
• En el caso de las paradas más pequeñas al costado de la ruta, la ubicación de una parada debe establecerse en la ubicación del poste de autobús cuando se pueda identificar uno. Cuando no se pueda identificar un poste de autobús específico, la ubicación debe colocarse en el lado correcto de la ruta y cerca de la ubicación real a lo largo de la ruta (idealmente, a menos de 10 m) donde se detiene el vehículo.

Extensiones adicionales de GTFS

Solo se requiere para los socios que desean mostrar información sobre precios y disponibilidad implementando las APIs de socios.

Extensión de venta de boletos de Google Transit

• Los socios deben implementar la especificación de la extensión de venta de boletos de Google Transit, que es un subconjunto de la extensión de GTFS-Ticketing.
• Imponemos los siguientes requisitos en los IDs de tickets:
  • Los IDs de tickets deben ser estables (es decir, se pueden cambiar con poca frecuencia y por una buena razón). En los casos en que cambien los IDs de tickets, se requerirá compatibilidad con versiones anteriores (durante un período mínimo de, al menos, 1 semana).
  • Para determinar los parámetros de SegmentKey en las solicitudes a la API, ticketing_trip_id (en trips.txt) y ticketing_stop_id (en ticketing_identifiers.txt) son obligatorios. La alternativa en stop_sequence no se admite porque no es estable.

GTFS-Fares v1

La referencia de GTFS Static especifica los archivos opcionales fare_attributes.txt y fare_rules.txt. Si un socio realiza la integración con las APIs de socios, no se deben proporcionar estos archivos.