Exigences GTFS

Le partenaire doit fournir un flux GTFS qui respecte toutes les spécifications standards, ainsi que celles listées ci-dessous. Ce flux doit couvrir tous les itinéraires que le partenaire souhaite afficher. Ces informations permettront d'afficher les horaires et les itinéraires sur Google. Notez qu'un partenaire peut choisir d'exposer des informations supplémentaires sur les prix et la disponibilité pour certains ou tous les itinéraires du flux fourni.

Exigences par défaut

Référence GTFS statique : toutes les exigences par défaut sont appliquées.

Bonnes pratiques GTFS : veuillez suivre les bonnes pratiques comme si elles étaient obligatoires.

Importation de flux GTFS - veuillez suivre cette procédure pour importer le flux GTFS.

Mises à jour : une fois les flux importés, ils peuvent être mis à jour en suivant la procédure décrite ici. En général, la propagation complète de ces mises à jour de flux peut prendre deux à trois jours.

Exigences supplémentaires

Champ d'application

  • Un seul flux GTFS doit couvrir un seul pays ou une partie d'un pays. Les trajets transfrontaliers doivent être fournis dans des flux distincts à l'échelle du continent. Si un flux GTFS couvre une zone plus grande qu'un pays, veuillez contacter l'équipe Travel Transport.
    • La taille des fichiers du fichier ZIP GTFS doit être inférieure à 4 Go. Les fichiers plus volumineux sont généralement le signe de mauvaises pratiques, comme le fait d'ignorer les options de compression proposées par frequencies.txt ou des fonctionnalités similaires. Cela peut entraîner des problèmes lors du traitement. Si vous pensez avoir besoin de fichiers de plus de 4 Go, veuillez contacter l'équipe Travel Transport à l'adresse transport-help@google.com.
    • Les données pour l'ensemble de la période d'exploitation future des services d'un flux GTFS doivent être fournies à chaque mise à jour des données GTFS. La segmentation des services par période n'est pas acceptable.
  • Toutes les dates d'un opérateur donné doivent être contenues dans un seul flux.

Traductions

  • Les traductions peuvent être fournies à l'aide de translations.txt et seront obligatoires dans les pays où :
    • les informations destinées aux utilisateurs peuvent être fournies dans différents scripts ou dans des scripts autres que le latin ;
    • les informations destinées aux utilisateurs peuvent être fournies dans plusieurs langues, ou les entités peuvent utiliser des noms différents dans ces langues (par exemple, Bruxelles/Brussel/Bruxelles).
  • Entités à traduire
    • Noms des agences, des arrêts et des itinéraires
    • Girouettes des trajets et des arrêts

Noms des itinéraires, noms courts des trajets et girouettes

  • Les girouettes doivent être fournies pour tous les trajets dans trips.txt (si la girouette reste la même tout au long du trajet) ou dans stop_times.txt (si la girouette change à différentes étapes du trajet).
  • Les girouettes doivent correspondre aux informations que les utilisateurs peuvent trouver sur le terrain. Par exemple, les girouettes affichées sur le véhicule ou sur les panneaux de signalisation.
  • Lorsqu'un itinéraire a un nom, il doit être fourni comme long_name dans routes.txt.
  • Lorsqu'un itinéraire a un numéro ou un identifiant alphanumérique spécifique qui s'applique à tous les trajets de cet itinéraire et dans les deux sens, il doit être fourni comme short_name dans routes.txt.
  • Lorsque les trajets de l'itinéraire ont des identifiants individuels (par exemple, des numéros de train), ces identifiants doivent être fournis comme noms courts de trajet.
  • Pour les services longue distance qui n'ont pas de numéro ni de nom d'itinéraire, le choix d'un nom d'itinéraire devient problématique. Dans ce cas, la règle générale est qu'une combinaison du nom de l'itinéraire et de la girouette doit aider l'utilisateur à identifier le véhicule sans ambiguïté. Par exemple, le nom de l'agence d'exploitation peut être utilisé comme nom d'itinéraire, tandis que la destination du trajet (si elle est affichée sur le véhicule) doit être utilisée comme girouette du trajet.

Exemples

  • Train Kamayani Express 11071 des chemins de fer indiens de Mumbai à Varanasi. Remarque : Le numéro 11071 identifie un trajet en train spécifique de Mumbai à Varanasi, et non l'itinéraire lui-même.
    • routes.txt:
      • short_name : <empty>
      • long_name: Kamayani Express
    • trips.txt:
      • trip_short_name: 11071
      • headsign: Varanasi
  • Bus de Buenos Aires à Córdoba exploité par Chevallier Bus. Remarque : Le bus qui a exploité ce service n'affiche pas de nom d'itinéraire particulier. Il affiche plutôt en évidence le nom de son agence d'exploitation et sa destination. Ce trajet spécifique n'a pas de numéro/identifiant individuel qui le distingue des autres trajets exploités par la même agence ou desservant le même itinéraire. Dans ce cas, il est acceptable d'utiliser "Chevallier" à la fois comme nom d'agence (dans agencies.txt) et comme long_name de l'itinéraire (dans routes.txt). La destination doit être utilisée pour la girouette. trip_short_name doit rester vide.
    • routes.txt:
      • short_name : <empty>
      • long_name: Chevallier
    • trips.txt:
      • trip_short_name : <empty>
      • headsign: Córdoba

Heures d'arrêt

arrival_time et departure_time doivent être fournis dans stop_times.txt.

Structure des trajets

  • Les trajets longue distance qui desservent plusieurs villes/zones doivent être fournis de bout en bout sans segmentation (par exemple,A->B->C et non [A->B,A->C,B->C]), où A, B et C sont des zones urbaines. Par exemple, un bus longue distance qui se rend de Buenos Aires à Córdoba, avec un arrêt à Rosario, doit être représenté comme un trajet avec des arrêts dans ces trois villes, et non comme trois trajets "Buenos Aires - Rosario", "Buenos Aires - Córdoba" et "Rosario - Córdoba".
  • Dans les cas où le fournisseur de données n'est pas en mesure d'obtenir les informations sur la structure correcte des trajets, des trajets segmentés de ville à ville peuvent être fournis au cas par cas. Si ces trajets de ville à ville comportent plusieurs points de prise en charge ou de dépose dans une ville (zone urbaine), la segmentation d'arrêt à arrêt n'est pas autorisée. Tous les points de prise en charge et tous les points de dépose doivent être listés dans un seul trajet.

Structures des stations

Pour les grandes stations comportant plusieurs quais/voies, les relations entre les stations et les quais doivent être spécifiées dans le flux, et les voies/quais spécifiques doivent être identifiés à l'aide du champ platform_code dans stops.txt. Les véhicules qui partent ou arrivent systématiquement à une voie ou un quai spécifique doivent être associés à cette voie ou à ce quai dans le flux GTFS. Si le quai ou la voie de départ ou d'arrivée change selon les jours/heures de départ, ces informations peuvent être fournies dans GTFS en temps réel.

Emplacements des stations/arrêts

  • Pour les grandes stations comportant plusieurs quais ou voies, l'emplacement de la station doit être défini sur celui de son entrée piétonne la plus visible (si la station dispose d'un bâtiment ou d'une structure) ou sur celui de la zone d'attente des passagers (pour les stations en extérieur).
  • Pour les arrêts plus petits situés au bord de la route, l'emplacement d'un arrêt doit être défini sur celui du poteau de bus lorsqu'il est identifiable. Lorsqu'un poteau de bus spécifique ne peut pas être identifié, l'emplacement doit être placé du bon côté de la route et à proximité de l'emplacement réel où le véhicule s'arrête (idéalement, à moins de 10 mètres).

Extensions GTFS supplémentaires

Obligatoire uniquement pour les partenaires qui souhaitent afficher des informations sur les prix/la disponibilité en implémentant les API partenaires.

Extension de billetterie Google Transports en commun

  • Les partenaires doivent implémenter la spécification de l'extension de billetterie Google Transports en commun qui est un sous-ensemble de l'extension GTFS-Ticketing.
  • Nous imposons les exigences suivantes concernant les ID de billetterie :
    • Les ID de billetterie doivent être stables (c'est-à-dire qu'ils ne doivent pas changer fréquemment, sauf pour une bonne raison). Dans les cas où les ID de billetterie changent, la rétrocompatibilité est requise (pour une période minimale d'au moins une semaine).
    • Pour déterminer les paramètres de SegmentKey dans les requêtes API, ticketing_trip_id (dans trips.txt) et ticketing_stop_id (dans ticketing_identifiers.txt) sont obligatoires. Le recours à stop_sequence n'est pas pris en charge , car il n'est pas stable.

GTFS-Fares v1

La référence GTFS statique spécifie les fichiers facultatifs fare_attributes.txt et fare_rules.txt. Si un partenaire s'intègre aux API partenaires, ces fichiers ne doivent pas être fournis.