Requisitos de GTFS

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

Requisitos predeterminados

Referencia estática de GTFS: Se aplican todos los requisitos predeterminados.

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

Carga de feeds GTFS: Sigue este proceso para subir el feed GTFS.

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

Requisitos adicionales

Permiso

• Un solo Feed GTFS debe abarcar un solo país o una parte de él. Los viajes que cruzan las fronteras de los países se deben proporcionar en feeds independientes para todo el continente. Si un Feed GTFS abarca cualquier tema más grande que un país, comunícate con el equipo de Transporte de Viajes.
  • Los archivos incluidos en el archivo ZIP de GTFS deben pesar menos de 4 GB. Por lo general, los archivos de mayor tamaño son un indicador de prácticas no recomendadas, 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 Travel Transport en [e-mail].
  • Con cada actualización de datos de GTFS, se deben proporcionar los datos de todo el período futuro de funcionamiento de los servicios de un Feed GTFS. No se acepta la segmentación de los servicios por períodos de tiempo diferentes.
• Todas las fechas de un operador determinado deben incluirse en un solo feed.

Traducciones

• Se pueden proporcionar traducciones a través de translations.txt y serán obligatorias en los países donde se cumple lo siguiente:
  • La información para los usuarios se puede proporcionar en alfabetos diferentes o en alfabetos que no sean el latino.
  • La información para los usuarios puede proporcionarse en varios idiomas o en los casos en que las entidades puedan usar nombres diferentes en esos idiomas (p.ej., Bruselas/Bruxelles)
• Entidades que se traducirán
  • nombres de empresas, paradas o rutas
  • señales de destino de viaje/parada

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 se mantiene constante durante el viaje) o en stop_times.txt (si la señal de destino cambia durante las diferentes etapas del viaje).
• Las señales de destino 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.
• Si una ruta tiene un número específico o un identificador alfanumérico que se aplica a todos los viajes de esa ruta y en ambas direcciones, se debe proporcionar como el nombre corto en routes.txt.
• Si los viajes dentro de la ruta tienen identificadores individuales (por ejemplo, números de tren), estos se deben proporcionar como nombres cortos de los viajes.
• En el caso de los servicios de larga distancia que no tienen números o nombres de ruta, elegir un nombre de ruta se vuelve problemático. Como lineamiento general, en estas situaciones, una combinación del nombre de la ruta y la señal de destino debería ayudar al usuario a identificar el vehículo de manera inequívoca. Por ejemplo, el nombre del operador se puede usar como el nombre de la ruta, mientras que el destino del viaje (si se muestra en el vehículo) como la señal de destino del viaje.

Ejemplos

• Tren Indian Railways Kamayani Express 11071 de Bombay a Varanasí. Nota: El número 11071 identifica un viaje en tren específico de Bombay a Varanasí, no la ruta en sí.
  • routes.txt:
    • nombre_corto: <vacío>
    • long_name: Expreso Kamayani
  • trips.txt:
    • trip_short_name: 11071
    • señal de destino: Varanasí
• Un autobús de Buenos Aires a Córdoba operado por Chevallier Bus. Nota: El autobús que operó este servicio no muestra un nombre de ruta en particular. En cambio, muestra de forma destacada el nombre del operador y el destino. Este viaje específico no tiene un número o identificador individual que lo distinga de otros viajes operados por la misma empresa o que tengan la misma ruta. En ese caso, es aceptable usar "Chevallier" como nombre de la empresa (en agencies.txt) y como nombre de la ruta (en routes.txt). El destino debe usarse para el cartel de destino. El campo trip_short_name debe quedar vacío.
  • routes.txt:
    • nombre_corto: <vacío>
    • long_name: Chevallier
  • trips.txt:
    • trip_short_name: <vacío>
    • señal de destino: Córdoba

Horarios de detención

Se deben proporcionar los valores arrival_time y expiration_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 y 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 como “Buenos Aires - Rosario”, “Buenos Aires - Córdoba” y “Rosario - Córdoba”.
• En los casos en los que el proveedor de datos no pueda obtener la información sobre la estructura de viaje correcta, se pueden proporcionar viajes segmentados de ciudad a ciudad según el caso. Si estos viajes de ciudad a ciudad tienen varios puntos de recogida o bajada en una misma ciudad (área de la ciudad), no se permite la segmentación de parada a parada, ya que todos los puntos de recogida y llegada deben incluirse en un único viaje.

Estructuras de las estaciones

En el caso de las estaciones grandes que tienen varias plataformas/compartimentos, se deben especificar las relaciones de estación-plataforma en el feed, y se deben identificar bahías o plataformas específicas mediante el campo platform_code en stops.txt. Los vehículos que siempre salen de una bahía o plataforma específica o llegan a ella deben vincularse a ella en el feed GTFS. Si la plataforma o la bahía de salida o llegada cambian en diferentes horarios o días de salida, esta información se puede proporcionar en GTFS Realtime.

Ubicaciones de estaciones y paradas

• En el caso de las estaciones grandes que tienen varias plataformas o bahías, la ubicación de la estación se debe establecer según la ubicación de la entrada peatonal más destacada (si la estación tiene un edificio o una estructura) o la ubicación del área de espera de pasajeros (para 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 una. 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, dentro de las cercanías, en la ubicación real de la ruta (idealmente, dentro de los 10 m) donde se detiene el vehículo.

Extensiones de GTFS adicionales

Solo es obligatorio para los socios que desean mostrar información sobre precios o disponibilidad mediante la implementación de 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 entradas de Google Transit que es un subconjunto de la extensión de venta de entradas de GTFS.
• Los IDs de venta de entradas deben cumplir con los siguientes requisitos:
  • Los IDs de venta de entradas deben ser estables (es decir, deben poder cambiar con poca frecuencia, por un buen motivo). En los casos en que cambien los IDs de venta de entradas, se requerirá retrocompatibilidad (por el período mínimo de al menos 1 semana).
  • Para determinar los parámetros de la SegmentKey en las solicitudes a la API, se obligatorio son los valores ticketing_trip_id (en trips.txt) y ticketing_stop_id (en ticketing_identifiers.txt). El resguardo en stop_sequence no es compatible porque no es estable.

Tarifas de GTFS v1

En la referencia de GTFS estáticas, se especifican los archivos opcionales fare_attributes.txt y fare_rules.txt. Si un socio se integra en las APIs de socios, no se deben proporcionar estos archivos.