Exigences GTFS

Le partenaire doit fournir un flux GTFS conforme à toutes les spécifications standards, en plus de celles indiquées ci-dessous. Ce flux doit couvrir tous les séjours que le partenaire souhaite afficher. Les informations sur les horaires et les itinéraires sont ainsi affichées sur Google. Sachez qu'un partenaire peut choisir de fournir des informations supplémentaires sur les prix et la disponibilité pour tout ou partie des séjours du flux fourni, s'il le souhaite.

Conditions par défaut

Static GTFS reference (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 requises.

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

Mises à jour: une fois les flux importés, vous pouvez les mettre à jour en suivant cette procédure. En général, la propagation complète de ces mises à jour de flux peut prendre deux à trois jours.

Exigences supplémentaires

Définition du champ d'application

• Un flux GTFS unique doit couvrir un seul pays ou une partie d'un pays. Les trajets qui traversent des frontières 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 chargée des transports touristiques.
  • Les fichiers inclus dans le fichier ZIP GTFS ne doivent pas dépasser 4 Go. Les fichiers plus volumineux sont généralement le signe de mauvaises pratiques, comme si les options de compression proposées par frequencies.txt ou des fonctionnalités similaires ont été ignorées. 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 [e-mail].
  • Les données pour l'ensemble de la période d'exploitation à venir des services dans un flux GTFS doivent être fournies avec chaque mise à jour des données GTFS. La segmentation des services par périodes différentes n'est pas acceptable.
• Toutes les dates d'un opérateur donné doivent figurer dans un seul flux.

Translations

• Les traductions peuvent être fournies via translations.txt. Elles seront obligatoires dans les pays où :
  • Les informations destinées aux utilisateurs peuvent être fournies dans des scripts différents ou non latins.
  • Les informations destinées aux utilisateurs peuvent être fournies dans plusieurs langues ou lorsque les entités peuvent utiliser des noms différents dans ces langues (par exemple, Bruxelles/Bruxelles/Bruxelles).
• Entités à traduire
  • noms d'agence/d'arrêt/d'itinéraire
  • girouettes de trajet/arrêt

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

• Des girouettes doivent être fournies pour tous les trajets, soit dans trips.txt (si elles restent cohérentes tout au long du trajet), soit dans stop_times.txt (si elles changent à différentes étapes du trajet).
• Les girouettes doivent correspondre aux informations que les utilisateurs peuvent trouver sur le terrain. (par exemple, des girouettes sur le véhicule ou sur les panneaux).
• Lorsqu'une route a un nom, celui-ci doit être fourni en tant que long_name dans routes.txt.
• Lorsqu'un itinéraire possède 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 indiqué en tant que short_name dans routes.txt.
• Lorsque des trajets au sein d'un itinéraire possèdent des identifiants individuels (par exemple, des numéros de train), ces identifiants doivent être fournis sous la forme de noms abrégés.
• Pour les services longue distance qui ne possèdent pas de numéro ni de nom d'itinéraire, le choix d'un nom d'itinéraire devient problématique. Dans ce cas, il est généralement recommandé d'associer le nom de l'itinéraire et la girouette à l'utilisateur afin d'identifier clairement le véhicule. Par exemple, le nom de l'organisme d'exploitation peut être utilisé comme nom de l'itinéraire, tandis que la destination du trajet (si elle est affichée sur le véhicule) doit être utilisée comme girouette.

Exemples

• Train 11071 de l'Indian Railways, Kamayani Express, 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: <vide>
    • long_name: Kamayani Express
  • trips.txt:
    • trip_short_name: 11071
    • headsign: Varanasi
• Bus de Buenos Aires à Cordoue, assuré par Chevallier Bus. Remarque: Le bus qui a assuré ce service n'affiche pas de nom d'itinéraire particulier. Au lieu de cela, il affiche de manière bien visible le nom de l'agence d'exploitation et sa destination. Ce trajet spécifique ne possède pas de numéro/d'identifiant individuel qui le distingue des autres trajets assurés par la même agence ou desservis sur le même itinéraire. Dans ce cas, vous pouvez utiliser "Chevallier" à la fois comme nom de réseau (dans agencies.txt) et comme nom long de l'itinéraire (dans routes.txt). La destination doit être utilisée pour la girouette. Le champ trip_short_name doit rester vide.
  • routes.txt:
    • short_name: <vide>
    • long_name: Chevallier
  • trips.txt:
    • trip_short_name: <vide>
    • headsign: Cordoue

Heures d'arrêt

Les champs "arrival_time" et "Department_time" doivent tous deux être définis dans le champ stop_times.txt.

Structure du trajet

• Les trajets longue distance desservant plusieurs villes/zones doivent être proposés de bout en bout sans segmentation (par exemple,A->B->C et non [A->B,A->C,B->C]), où A, B et C correspondent à des zones urbaines. Par exemple, un bus longue distance reliant Buenos Aires à Cordoue et 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 - Cordoue" et "Rosario - Córdoba".
• Si le fournisseur de données n'est pas en mesure d'obtenir les informations sur la structure de trajets appropriée, des trajets ville à ville segmentés peuvent être fournis au cas par cas. Si de tels trajets d'une ville à l'autre comportent plusieurs lieux de prise en charge ou de dépose dans une même ville (zone urbaine), la segmentation des arrêts à des arrêts n'est pas autorisée. Tous les points de prise en charge et tous les lieux de dépôt doivent être répertoriés dans un seul trajet.

Structures des stations

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

Emplacement des gares/stations

• Pour les grandes stations disposant de plusieurs plates-formes ou aires, l'emplacement de la station doit être défini sur l'emplacement de son entrée piétonne la plus importante (si elle comporte un bâtiment ou une structure), ou sur la zone d'attente des passagers (pour les stations extérieures).
• Pour les arrêts de plus petite taille sur le côté d'une route, l'emplacement d'un arrêt doit être défini sur l'emplacement du poteau d'autobus lorsqu'il est possible d'en identifier un. Lorsqu'il est impossible d'identifier un poteau d'autobus spécifique, l'emplacement doit être placé du bon côté de la route et à proximité de l'endroit où s'arrête le véhicule le long de la route (idéalement, dans un rayon de 10 m).

Extensions GTFS supplémentaires

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

Extension de billetterie dans Google Transports en commun

• Les partenaires doivent mettre en œuvre 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 aux ID de billetterie :
  • Les ID de billetterie doivent être stables (c'est-à-dire qu'ils ne peuvent être modifiés que rarement, pour une bonne raison). En cas de changement des ID de billetterie, une rétrocompatibilité est requise (pour une période minimale d'une semaine au moins).
  • 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 remplacement sur stop_sequence n'est pas compatible, car il n'est pas stable.

GTFS-Fares v1

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