Bonnes pratiques concernant le format GTFS

GTFS principal

Vous trouverez ci-dessous les pratiques recommandées pour décrire des services de transports en commun dans le format GTFS (General Transit Feed Specification). Ces bonnes pratiques ont été synthétisées sur la base de l'expérience des membres du groupe de travail en charge des bonnes pratiques concernant le format GTFS et des recommandations liées aux bonnes pratiques applicables au format GTFS spécifiques à l'application. Pour en savoir plus, consultez les questions fréquentes.

Structure du document

Les bonnes pratiques sont classées dans trois sections principales :

Questions fréquentes

Pourquoi ces bonnes pratiques concernant le format GTFS sont-elles importantes ?

Les objectifs des bonnes pratiques concernant le format GTFS sont les suivants :

  • Améliorer l'expérience des utilisateurs finaux dans les applications de transports en commun
  • Favoriser l'interopérabilité des données pour permettre aux développeurs de logiciels de déployer et de faire évoluer plus facilement leurs applications, leurs produits et leurs services
  • Faciliter l'utilisation du format GTFS dans différentes catégories d'applications (au-delà de la planification de trajets, son objet initial)

Sans bonnes pratiques coordonnées concernant le format GTFS, différentes applications l'utilisant peuvent établir des exigences et des attentes de manière non coordonnée, ce qui peut donner lieu à des exigences et des ensembles de données spécifiques à l'application différents, ainsi qu'à une réduction de l'interopérabilité. Avant la publication des bonnes pratiques, il régnait une certaine ambiguïté et des désaccords autour de ce qui constitue le format correct de données GTFS.

Comment ont-elles été développées ? Par qui ?

Ces bonnes pratiques ont été développées par un groupe de travail composé de 17 organisations qui travaillent avec le format GTFS, parmi lesquelles des fournisseurs d'applications, des consommateurs de données, des fournisseurs de services de transports en commun et des consultants fortement impliqués dans le format GTFS. Le groupe de travail a été mis en place par le Rocky Mountain Institute.

Toutes les bonnes pratiques ont fait l'objet d'un vote des membres du groupe de travail. La plupart des bonnes pratiques ont été approuvées à l'unanimité. Dans une minorité de cas, les bonnes pratiques ont été approuvées par une vaste majorité d'organisations.

Pourquoi ne pas simplement modifier la référence GTFS ?

C'est une bonne question. L'examen de la spécification, de l'utilisation des données et des besoins a en effet donné lieu à certains changements au niveau de la spécification (reportez-vous aux demandes d'extraction clôturées sur GitHub). Les modifications apportées à la référence de la spécification sont soumises à un niveau d'examen et de commentaire plus élevé que les bonnes pratiques. Il était toutefois toujours nécessaire de s'accorder sur un ensemble clair de recommandations concernant les bonnes pratiques.

Le groupe de travail prévoit que certaines bonnes pratiques concernant le format GTFS finiront par intégrer la référence GTFS principale.

Les outils de validation GTFS vérifient-ils si ces bonnes pratiques sont respectées ?

Actuellement, aucun outil de validation ne vérifie que toutes les bonnes pratiques sont respectées. Plusieurs outils de validation vérifient le respect de certaines de ces bonnes pratiques. Pour obtenir une liste des outils de validation GTFS, reportez-vous à l'article Tester des flux. Si vous concevez un outil de validation GTFS qui fait référence à ces bonnes pratiques, veuillez envoyer un e-mail à l'adresse gtfs@rmi.org.

Je représente une agence de transports en commun. Que puis-je faire pour que nos fournisseurs de services logiciels respectent ces bonnes pratiques ?

Invitez votre fournisseur de services logiciels à suivre ces bonnes pratiques. Nous vous recommandons d'ajouter en référence l'URL vers les bonnes pratiques concernant le format GTFS, ainsi que la référence principale concernant la spécification dans le cadre de la fourniture de logiciels GTFS.

Que dois-je faire si je remarque qu'un flux de données GTFS ne respecte pas ces bonnes pratiques ?

Identifiez le contact associé au flux à l'aide des champs feed_contact_email ou feed_contact_url proposés dans feed_info.txt s'ils existent. Vous pouvez également rechercher les coordonnées sur le site Web de l'agence de transports en commun ou du producteur du flux. Lorsque vous communiquez le problème au producteur du flux, faites référence à la bonne pratique GTFS en question. Reportez-vous à la section Faire référence à ce document.

Je souhaite proposer une modification ou un ajout aux bonnes pratiques. Comment procéder ?

Envoyez un e-mail à l'adresse gtfs@rmi.org, soumettez votre proposition ou effectuez une demande d'extraction dans le dépôt GitHub des bonnes pratiques concernant le format GTFS.

Comment puis-je m'impliquer ?

Envoyez un e-mail à gtfs@rmi.org.

Bonnes pratiques générales et concernant la publication d'ensembles de données

Recommandations générales
Publiez vos ensembles de données sous une URL publique disponible en permanence qui inclut le nom du fichier ZIP (par exemple, https://www.agency.org/gtfs/gtfs.zip). Dans l'idéal, l'URL doit permettre un téléchargement direct, sans nécessiter de connexion pour accéder au fichier, afin de faciliter le téléchargement via l'utilisation d'applications logicielles. Bien qu'il soit recommandé (et courant) de créer un ensemble de données GTFS publiquement téléchargeable, si un fournisseur de données doit contrôler l'accès aux données GTFS pour des questions de licence ou autre, il est recommandé de contrôler l'accès à l'ensemble de données GTFS à l'aide de clés API, ce qui facilite les téléchargements automatiques.
Les données GTFS sont publiées dans des itérations de sorte qu'un fichier unique à un emplacement stable contienne toujours la dernière description officielle du service pour une ou plusieurs agences de transports en commun.
Dans la mesure du possible, conservez des identifiants permanents (champs d'identifiant) pour stop_id, route_id et agency_id pour les itérations de données.
Un ensemble de données GTFS doit contenir le service actuel et à venir (parfois appelé "ensemble de données fusionné"). Vous pouvez utiliser la fonction de fusion de l'outil transitfeed de Google pour créer un ensemble de données fusionné à partir de deux flux GTFS différents.
  • L'ensemble de données GTFS publié doit être valide pendant au moins les sept jours suivants et, idéalement, tant que l'opérateur a l'assurance que l'horaire sera respecté.
  • Si possible, l'ensemble de données GTFS doit couvrir au moins les 30 jours de service suivants.
Supprimez les anciens services (calendriers arrivés à expiration) du flux.
Si une modification du service doit prendre effet dans sept jours ou moins, indiquez-la via un flux GTFS-realtime (conseils de service ou mises à jour des trajets) plutôt qu'à l'aide d'un ensemble de données GTFS statique.
Le serveur Web qui héberge les données GTFS doit être configuré de manière à indiquer correctement la date de modification du fichier (reportez-vous au document HTTP/1.1 - Request for Comments 2616, conformément à la section 14.29).

Recommandations concernant les bonnes pratiques organisées par fichier

Cette section affiche les pratiques organisées par fichier et par champ, conformément à la référence GTFS.

Tous les fichiers

Nom du champ Recommandation
Majuscules et minuscules Toutes les chaînes de texte vues par les clients (y compris les noms des arrêts, les noms des itinéraires et les girouettes) doivent utiliser des majuscules et des minuscules (pas uniquement des majuscules), en fonction des conventions locales d'utilisation des majuscules et des minuscules pour les écrans permettant d'afficher des caractères en minuscules.
Exemples :
Brighton Churchill Square
Villiers-Sur-Marne
Market Street
Abréviations Évitez d'utiliser des abréviations dans l'ensemble du flux pour les noms et d'autres types de texte ("St." pour "Street", par exemple), sauf si un lieu est désigné par son nom abrégé ("JFK Airport", par exemple). Les abréviations peuvent poser des problèmes d'accessibilité pour les logiciels de lecture d'écran et les interfaces vocales. Il est possible de concevoir des logiciels de raccourcissement qui permettent de transformer de façon fiable des mots entiers en abréviations. La conversion d'abréviations en mots entiers présente quant à elle un risque d'erreur plus élevé.

agency.txt

Nom du champ Recommandation
agency_id Doit être inclus, même si le flux ne comporte qu'une seule agence. (Voir également la recommandation consistant à inclure agency_id dans routes.txt et fare_attributes.txt.)
agency_lang Doit être inclus.
agency_phone Doit être inclus, à moins qu'aucun numéro de téléphone de service client n'existe.
agency_email Doit être inclus, à moins qu'aucune adresse e-mail de service client n'existe.
agency_fare_url Doit être inclus, à moins que les services de l'agence soient entièrement gratuits.

Exemples :

  • Les services d'autobus sont assurés par plusieurs petites agences de transport en autobus. Cependant, une plus grande agence s'occupe de la gestion des horaires et des billets. Du point de vue de l'utilisateur, c'est cette agence-là qui gère le réseau. Dans cet exemple, c'est cette plus grande agence qui doit être définie en tant que telle dans le flux. Même si les données sont réparties en interne entre différents organismes, seule une agence doit figurer dans le flux.
  • L'organisme responsable de fournir le flux gère également la vente des billets. Cependant, ce sont des agences différentes qui assurent les services, et les utilisateurs identifient celles-ci comme étant responsables du transport. Dans cet exemple, ce sont les agences qui assurent directement le service de transport qui doivent être définies comme telles dans le flux.

stops.txt

Nom du champ Recommandation
stop_id Les arrêts situés à des emplacements physiques différents (par exemple, différents lieux précis pour les véhicules sur des itinéraires spécifiques, pouvant être identifiés par des panneaux, des abris ou d'autres informations publiques, situés à différents coins de rue ou représentant une installation d'embarquement différente, comme une plate-forme ou un arrêt d'autobus, même s'ils sont proches) doivent être associés à un champ stop_id différent.
Le champ stop_id correspond à un identifiant interne qui n'est pas destiné à être vu par les usagers.
Utilisez un même champ stop_id pour des arrêts identiques dans les itérations de données (consultez Bonnes pratiques générales et concernant la publication d'ensembles de données).
stop_name Le champ stop_name doit correspondre au nom public de l'agence pour l'arrêt, la station ou l'installation d'embarquement (par exemple, ce qui figure sur un horaire publié en ligne ou affiché sur place).
Lorsque aucun nom d'arrêt n'est publié, respectez des conventions d'attribution de noms cohérentes pour l'ensemble du flux.
Évitez d'utiliser des abréviations, sauf dans le cas des lieux généralement désignés par un nom abrégé. Reportez-vous à la section dédiée aux abréviations (#2) sous Tous les fichiers.
Indiquez des noms d'arrêts avec des majuscules et des minuscules en respectant les conventions locales, comme recommandé pour tous les champs de texte destinés aux clients.
Par défaut, le champ stop_name ne doit pas contenir de mots génériques ni redondants tels que "Station" ou "Arrêt", mais certains cas spéciaux sont autorisés.
  • Si le mot fait partie du nom ("Station Nord", "Arrêt Hôtel de ville").
  • Si le champ stop_name est trop générique (par exemple, s'il s'agit du nom de la ville). “Station”, “Terminal” ou d'autres mots permettent de clarifier le sens.
stop_lat et stop_lon Les emplacements des arrêts doivent être aussi précis que possible. Les emplacements des arrêts doivent être corrects (marge d'erreur inférieure à quatre mètres par rapport à la position réelle de l'arrêt).
Les emplacements des arrêts doivent être placés à proximité immédiate des lieux de passage des piétons, là où les usagers montent à bord (c'est-à-dire, du bon côté de la rue).
Si l'emplacement d'un arrêt est partagé entre des flux de données distincts (par exemple, deux agences utilisent exactement le même arrêt ou la même installation d'embarquement), indiquez que l'arrêt est partagé en utilisant exactement les mêmes champs stop_lat et stop_lon pour les deux arrêts.
stop_code Le champ stop_code doit être inclus dans le flux GTFS si des numéros d'arrêt ou des identifiants courts sont affichés auprès des usagers.
parent_station et location_type De nombreux terminaux et de nombreuses stations disposent de plusieurs types d'installations d'embarquement (selon le mode de transport, il peut s'agir d'un arrêt d'autobus, d'une plate-forme, d'un quai, d'une porte, etc.). Dans de tels cas, les producteurs de flux doivent décrire les stations, les installations d'embarquement (également appelées "arrêts enfants") et leur relation.
  • La station ou le terminal doit être défini comme une entrée dans le champ stops.txt avec location_type = 1.
  • Chaque installation d'embarquement doit être définie comme un arrêt avec location_type = 0. Le champ parent_station doit faire référence à l'identifiant stop_id de la station dans laquelle se trouve l'installation d'embarquement.
Lorsque vous attribuez un nom à la station et aux arrêts enfants, définissez des noms facilement reconnaissables par les usagers. Ces informations doivent pouvoir aider les usagers à identifier la station et l'installation d'embarquement (arrêt d'autobus, plate-forme, quai, porte, etc.).
Nom de la station parente Nom de l'arrêt enfant
Union Station à Chicago Union Station à Chicago Plate-forme 19
Terminal Ferry Building de San Francisco Terminal Ferry Building de San Francisco Porte E
Centre de transports en commun Centre-ville Centre de transports en commun Centre-ville Arrêt B

routes.txt

Nom du champ Recommandation
agency_id Doit être inclus s'il est défini dans agency.txt.
route_short_name Incluez route_short_name en cas de désignation brève du service. Il doit s'agir du nom du service connu des usagers (12 caractères maximum).
route_long_name Définition de la référence de la spécification : Ce nom est généralement plus descriptif que route_short_name. Il inclut souvent la destination ou l'arrêt associés à l'itinéraire. Vous devez spécifier au moins route_short_name ou route_long_name, ou les deux si nécessaire. Si le nom de l'itinéraire n'est pas long, veuillez spécifier une valeur route_short_name et utiliser une chaîne vide pour ce champ.

Voici des exemples de types de noms longs :

Parcours principal ou couloir
Nom de l'itinéraire Format Agence
"N"/"Judah" route_short_name/
route_long_name
Muni à San Francisco
"6"/"ML King Jr Blvd" route_short_name/
route_long_name
TriMet à Portland, Oregon.
"6"/"Nation – Étoile" route_short_name/
route_long_name
RATP à Paris
"U2"/"Pankow – Ruhleben" route_short_name/
route_long_name
BVG à Berlin
Description du service
"Navette locale à Hartwell"
route_long_name ne doit pas contenir route_short_name.
Incluez la désignation complète, y compris une identité de service, lorsque vous remplissez route_long_name. Exemples :
Identité du service Recommandation Exemples
"Métro léger MAX"
TriMet de Portland (Oregon)
L'élément route_long_name doit inclure la marque (MAX) et la désignation spécifique de l'itinéraire. "Ligne rouge MAX"
"Ligne bleue MAX"
"Rapid Ride"
ABQ Ride d'Albuquerque (Nouveau-Mexique)
L'élément route_long_name doit inclure la marque (Rapid Ride) et la désignation spécifique de l'itinéraire. "Ligne rouge Rapid Ride"
"Ligne bleue Rapid Ride"
route_id Tous les trajets d'un itinéraire donné doivent faire référence au même route_id.
  • Des sens de direction différents dans un itinéraire ne doivent pas être séparés dans des valeurs route_id distinctes.
  • Des services différenciés par tranches horaires pour un même itinéraire ne doivent pas être séparés dans des valeurs route_id distinctes. En d'autres termes, ne créez pas d'entrées différentes dans routes.txt pour les services "Centre-ville matin" et "Centre-ville après-midi".
Si un groupe d'itinéraires inclut des branches associées à un nom différent (par exemple, 1A et 1B), suivez les recommandations dans le dossier branches de l'itinéraire pour déterminer les valeurs route_short_name et route_long_name.
route_color et route_text_color Ces valeurs doivent correspondre à la signalétique ainsi qu'aux informations du client imprimées et disponibles en ligne (elles ne doivent donc pas être incluses si elles n'existent pas ailleurs).

trips.txt

  • Voir un cas particulier d'itinéraire en boucle : les itinéraires en boucle sont des cas dans lesquels les trajets commencent et se terminent au même arrêt, par opposition aux itinéraires linéaires, qui présentent deux terminus différents. Les itinéraires en boucle doivent être décrits en respectant des pratiques spécifiques. Reportez-vous au cas d'itinéraire en boucle.
  • Voir un cas particulier d'itinéraire en lasso : les itinéraires en lasso sont un mélange entre les formes linéaire et en boucle. Dans ce cas-ci, les véhicules circulent sur une boucle pour une partie de l'itinéraire seulement. Les itinéraires en lasso doivent être décrits en respectant des pratiques spécifiques. Reportez-vous au cas d'itinéraire en lasso.
Nom du champ Recommandation
trip_headsign N'indiquez pas de noms d'itinéraires (correspondant aux valeurs route_short_name et route_long_name) dans le champ trip_headsign ou stop_headsign.
Ce champ doit contenir le texte désignant la destination, l'itinéraire ou le trajet affiché sur la girouette du véhicule, qui permet de distinguer différents trajets d'un itinéraire. La cohérence avec les informations d'itinéraire affichées sur le véhicule constitue l'objectif principal et le plus important pour identifier les girouettes fournies dans les ensembles de données GTFS. N'incluez d'autres informations que si elles ne mettent pas à mal cet objectif principal. Si les girouettes changent au cours d'un trajet, remplacez trip_headsign par stop_times.stop_headsign. Vous trouverez ci-dessous des recommandations pour différents cas possibles :
exemple_de_tableau :
Description de l'itinéraire Recommandation
2A. Destination uniquement Indiquez le terminus (la destination). Par exemple, "Centre de transports en commun", "Portland City" ou "Janzen Beach".
2B. Destinations avec points de cheminement <destination> via <point de cheminement> "Highgate via Charing Cross". Si les points de cheminement sont supprimés de la girouette une fois que le véhicule les a passés, utilisez stop_times.stop_headsign pour mettre à jour la girouette.
2C. Nom de lieu régional avec arrêts locaux Si l'itinéraire comporte plusieurs arrêts dans la ville ou l'arrondissement de destination, utilisez stop_times.stop_headsign une fois la ville de destination atteinte.
2D. Direction uniquement Utilisez des termes tels que "Direction Nord", "Aller", "Sens horaire" ou autre.
2E. Direction avec destination <direction> vers <nom du terminus>, par exemple "Direction Sud vers San José".
2F. Direction avec destination et points de cheminement <direction> via <point de cheminement> vers <destination> ("Direction Nord via Charing Cross vers Highgate").
Ne faites pas commencer le texte de la girouette par les mots "Vers" ou "En direction de".
direction_id Si des trajets d'un itinéraire desservent des directions opposées, faites la distinction entre ces groupes de trajets avec le champ direction_id, à l'aide de valeurs 0 et 1.
Utilisez les valeurs 0 et 1 de manière cohérente pour la totalité de l'ensemble de données. Par exemple :
  • Si 1 = Retour sur l'itinéraire rouge, 1 = Retour sur l'itinéraire vert
  • Si 1 = Direction Nord sur l'itinéraire X, 1 = Direction Nord sur l'itinéraire Y
  • Si 1 = Sens horaire sur l'itinéraire X, 1 = Sens horaire sur l'itinéraire Y

stop_times.txt

Itinéraires en boucle : pour les itinéraires en boucle, il est nécessaire de porter une attention particulière à stop_times. (Voir Cas des itinéraires en boucle)

Nom du champ Recommandation
pickup_type et drop_off_type Les trajets qui ne génèrent pas de revenus (trajets à vide) qui ne proposent pas de service aux usagers doivent être marqués avec les valeurs pickup_type et drop_off_type de 1 pour toutes les lignes stop_times.
Pour les trajets qui génèrent des revenus, les "repères temporels" internes permettant de contrôler les performances opérationnelles et les autres lieux (par exemple, les dépôts d'autobus où les usagers ne peuvent pas monter à bord), vous devez indiquer pickup_type = 1 (prise en charge indisponible) et drop_off_type = 1 (dépôt indisponible).
timepoint Le champ timepoint doit être renseigné. Il spécifie le stop_times que l'opérateur tentera de respecter strictement (timepoint=1) et indique que les autres heures d'arrêt sont des estimations (timepoint=0).
arrival_time et departure_time Les champs arrival_time et departure_time doivent indiquer des valeurs de temps dans la mesure du possible, y compris les durées estimées ou interpolées (non contractuelles) entre les repères temporels.
stop_headsign

Les valeurs stop_headsign remplacent l'élément trip_headsign (dans trips.txt). Les valeurs stop_headsign doivent être fournies lorsque le texte affiché sur la girouette change au cours d'un trajet. Les valeurs stop_headsign ne s'étendent pas aux arrêts suivants. Par conséquent, les valeurs doivent être répétées si la girouette mentionnant l'arrêt ne change pas. En général, les valeurs de la girouette doivent également correspondre aux panneaux dans les stations.

Dans les cas ci-dessous, "Direction Sud" pourrait induire les clients en erreur, car cet itinéraire ne figure pas sur les panneaux des stations.

À New York, pour les deux "Direction Sud" :
Pour les lignes stop_times.txt : Utilisez la valeur stop_headsign :
Jusqu'à Manhattan Manhattan & Brooklyn
Jusqu'au centre-ville Downtown & Brooklyn
Jusqu'à Brooklyn Brooklyn
Une fois à Brooklyn Brooklyn (New Lots Av)
À Boston, pour la ligne rouge "Direction Sud", pour la branche Braintree :
Pour les lignes stop_times.txt : Utilisez la valeur stop_headsign :
Jusqu'au centre-ville Inbound to Braintree
Une fois dans le centre-ville Braintree
Après le centre-ville Outbound to Braintree
shape_dist_traveled shape_dist_traveled doit être fourni pour les tracés en boucle ou rectilignes (le véhicule traverse ou emprunte la même portion d'alignement en un trajet). Consultez la recommandation pour shapes.shape_dist_traveled.

calendar.txt

Nom du champ Recommandation
Tous les champs calendar_dates.txt ne doit contenir qu'un nombre limité d'exceptions aux horaires. Pour définir les horaires de service standards, utilisez calendar.txt.
L'inclusion d'un champ calendar.service_name permet également d'améliorer la lisibilité du flux GTFS, même si cette approche n'est pas adoptée dans la spécification.

calendar_dates.txt

Nom du champ Recommandation
Tous les champs calendar_dates.txt ne doit contenir qu'un nombre limité d'exceptions aux horaires. Pour définir les horaires de service standards, utilisez calendar.txt.
L'inclusion d'un champ calendar.service_name permet également d'améliorer la lisibilité du flux GTFS, même si cette approche n'est pas adoptée dans la spécification.

fare_attributes.txt

Nom du champ Recommandation
Tous les champs agency_id doit être inclus dans fare_attributes.txt si le champ est inclus dans agency.txt.
Si un système de tarification ne peut pas être modélisé avec précision, laissez le champ vide afin d'éviter toute confusion.
Incluez les tarifs (fare_attributes.txt et fare_rules.txt) et modélisez-les avec le plus de précision possible. Dans les cas limites où les tarifs ne peuvent pas être modélisés de manière précise, il convient d'afficher le tarif le plus cher plutôt que le moins cher pour éviter que les clients ne disposant pas du montant requis montent à bord. Si la grande majorité des tarifs ne peuvent pas être modélisés correctement, n'incluez pas d'informations tarifaires dans le flux.

fare_rules.txt

Nom du champ Recommandation
Tous les champs agency_id doit être inclus dans fare_attributes.txt si le champ est inclus dans agency.txt.
Si un système de tarification ne peut pas être modélisé avec précision, laissez le champ vide afin d'éviter toute confusion.
Incluez les tarifs (fare_attributes.txt et fare_rules.txt) et modélisez-les avec le plus de précision possible. Dans les cas limites où les tarifs ne peuvent pas être modélisés de manière précise, il convient d'afficher le tarif le plus cher plutôt que le moins cher pour éviter que les clients ne disposant pas du montant requis montent à bord. Si la grande majorité des tarifs ne peuvent pas être modélisés correctement, n'incluez pas d'informations tarifaires dans le flux.

shapes.txt

Nom du champ Recommandation
Tous les champs Idéalement, pour les alignements partagés (dans le cas où les itinéraires 1 et 2 empruntent le même segment de route ou de voie), la partie partagée de l'alignement doit correspondre exactement. Cela facilite la création de cartes de transports en commun de qualité.
Les alignements doivent suivre la ligne médiane du côté droit de la route sur laquelle le véhicule circule. Il peut s'agir de la ligne médiane de la rue si aucune voie n'est spécifiée, ou de la ligne médiane du côté de la route qui va dans le sens de déplacement du véhicule.

Les alignements ne doivent pas comporter de tournant soudain pour atteindre l'arrêt, la plate-forme ou le lieu d'embarquement.
shape_dist_traveled

Doit être fourni dans shapes.txt et stop_times.txt si un alignement inclut un tracé en boucle ou rectiligne (le véhicule traverse ou emprunte la même portion d'alignement en un trajet).

Itinéraire rectiligne

Si un véhicule retrace ou traverse l'alignement de l'itinéraire à certains points d'un trajet, shape_dist_traveled est important pour clarifier la façon dont des portions des points dans shapes.txt correspondent aux entrées dans stop_times.txt.

Le champ shape_dist_traveled permet à l'agence de spécifier précisément comment les arrêts du fichier stop_times.txt s'intègrent à leur forme respective. Généralement, la valeur utilisée pour le champ shape_dist_traveled correspond à la distance à partir du début du tracé, tel qu'il serait parcouru par le véhicule (pensez, par exemple, à un relevé de compteur kilométrique).
  • Les alignements d'itinéraires (dans shapes.txt) doivent se trouver dans un rayon de 100 mètres autour des arrêts desservis lors d'un trajet.
  • Simplifiez les alignements afin que shapes.txt ne contienne pas de points superflus (par exemple, supprimez les points supplémentaires des segments de ligne droite ; consultez la discussion sur le problème de simplification des lignes).

feed_info.txt

feed_info.txt doit être inclus, ainsi que tous les champs ci-dessous.

Nom du champ Recommandation
feed_start_date et feed_end_date Doit être inclus.
feed_version Doit être inclus.
feed_contact_email et feed_contact_url Veuillez en renseigner au moins un.

frequencies.txt

Nom du champ Recommandation
Tous les champs Les heures d'arrêt réelles sont ignorées pour les trajets référencés par frequencies.txt. Seuls les intervalles de temps de trajet entre les arrêts sont pris en compte pour les trajets basés sur la fréquence. Pour plus de clarté et de lisibilité, il est recommandé de faire en sorte que le premier arrêt d'un trajet référencé dans le champ frequencies.txt commence à 00:00:00 (première valeur arrival_time de 00:00:00).
block_id Peut être fourni pour les trajets basés sur la fréquence.

transfers.txt

transfers.transfer_type peut être l'une des quatre valeurs définies dans le flux GTFS. Ces valeurs définies pour transfer_type sont tirées de la spécification GTFS ci-dessous, avec des recommandations concernant les bonnes pratiques supplémentaires.

Nom du champ Recommandation
transfer_type 0 ou (vide) : point de correspondance recommandé entre des itinéraires.

Si plusieurs possibilités de correspondance comprennent une option de meilleure qualité (par exemple, un centre de transports en commun avec des équipements supplémentaires, ou une station disposant d'installations ou de plates-formes d'embarquement adjacentes ou connectées), spécifiez un point de correspondance recommandé.

1 : point de correspondance temporisé entre deux itinéraires. Le véhicule sur le point de partir doit attendre celui sur le point d'arriver et laisser suffisamment de temps aux usagers pour qu'ils puissent prendre la correspondance.

Ce type de transfert ne tient pas compte d'un intervalle requis pour effectuer des transferts de manière fiable. Par exemple, Google Maps part du principe que les usagers ont besoin de trois minutes pour prendre une correspondance en toute sécurité. D'autres applications peuvent utiliser d'autres valeurs par défaut.

2 : cette correspondance nécessite une durée minimale entre l'heure d'arrivée et l'heure de départ. Spécifiez la durée en question dans le champ min_transfer_time.

Spécifiez une durée minimale de correspondance si des obstacles ou d'autres facteurs risquent d'allonger le temps de trajet entre plusieurs arrêts.

3 : aucune correspondance ne peut être assurée à cet endroit.

Spécifiez cette valeur si les correspondances ne sont pas possibles en raison d'obstacles physiques, ou si elles sont dangereuses ou compliquées en raison de routes difficiles à traverser ou de trous au niveau du réseau piéton.

Si les correspondances sans changement ("en bloc") sont autorisées entre les trajets, le dernier arrêt du trajet d'arrivée doit correspondre au premier arrêt du trajet de départ.

Recommandations liées aux bonnes pratiques organisées par cas

Cette section concerne des cas particuliers avec des implications au niveau des fichiers et des champs.

Itinéraires en boucle

Dans le cas des itinéraires en boucle, les trajets des véhicules commencent et se terminent au même endroit (il peut parfois s'agir d'un centre de transports en commun ou de correspondance). Les véhicules fonctionnent généralement en continu et permettent aux usagers de rester à bord, puisqu'ils poursuivent leur boucle.

Ci-dessous : itinéraire en boucle. Le véhicule retourne au point de départ en un trajet. Certains itinéraires en boucle proposent des trajets dans un sens, et d'autres dans deux sens.
Itinéraire en boucle

Appliquez donc les recommandations concernant les girouettes afin d'indiquer aux usagers le sens du trajet.

Pour indiquer le changement de sens lors du voyage, renseignez la valeur stop_headsigns dans le fichier stop_times.txt. Le champ stop_headsign décrit le sens du trajet au départ de l'arrêt pour lequel il est défini. Si vous ajoutez stop_headsigns à chaque arrêt d'un trajet, vous pourrez modifier les informations de la girouette au cours du trajet.

Si l'itinéraire va directement d'un point à un autre, en sens aller et retour, ne définissez pas de trajet circulaire dans le fichier stop_times.txt. Séparez plutôt ce type de trajet en deux trajets à sens inverse.

Exemples de modélisation d'un trajet circulaire :

Trajet circulaire avec modification de la girouette à chaque arrêt :

Trip_id arrival_time departure_time stop_id stop_sequence stop_headsign
trip_1 06:10:00 06:10:00 stop_A 1 "B"
trip_1 06:15:00 06:15:00 stop_B 2 "C"
trip_1 06:20:00 06:20:00 stop_C 3 "D"
trip_1 06:25:00 06:25:00 stop_D 4 "E"
trip_1 06:30:00 06:30:00 stop_E 5 "A"
trip_1 06:35:00 06:35:00 stop_A 6 ""

Trajet circulaire avec deux instances de girouette :

Trip_id arrival_time departure_time stop_id stop_sequence stop_headsign
trip_1 06:10:00 06:10:00 stop_A 1 "outbound"
trip_1 06:15:00 06:15:00 stop_B 2 "outbound"
trip_1 06:20:00 06:20:00 stop_C 3 "outbound"
trip_1 06:25:00 06:25:00 stop_D 4 "inbound"
trip_1 06:30:00 06:30:00 stop_E 5 "inbound"
trip_1 06:35:00 06:35:00 stop_F 6 "inbound"
trip_1 06:40:00 06:40:00 stop_A 7 ""
Nom du champ Recommandation
trips.trip_id Modélisez le trajet aller-retour complet de la boucle en un seul trajet.
stop_times.stop_id Incluez le premier/dernier arrêt deux fois dans stop_times.txt pour le trajet en boucle. Vous trouverez un exemple ci-dessous. Souvent, un itinéraire en boucle peut inclure les premiers et les derniers trajets qui n'effectuent pas la totalité de la boucle. Incluez ces trajets également.
trip_id stop_id stop_sequence
9000 101 1
9000 102 2
9000 103 3
9000 101 4
trips.direction_id Si les véhicules empruntent le trajet en boucle dans deux sens opposés (dans le sens des aiguilles d'une montre et dans le sens inverse des aiguilles d'une montre), indiquez direction_id comme 0 ou 1.
trips.block_id Indiquez les trajets en boucle continus avec le même block_id.

Itinéraires en lasso

Les itinéraires en lasso combinent des aspects d'un itinéraire en boucle et d'un itinéraire directionnel.

Ci-dessous : itinéraires en lasso allant du point A au point A via le point B et composés de trois sections :
  • Section directe du point A au point B
  • Boucle depuis et vers le point B
  • Section directe du point B au point A
Itinéraire en lasso
Exemples :
Itinéraires de métro (Chicago)
Itinéraires d'autobus entre la banlieue et le centre-ville (St. Albert ou Edmonton)
Ligne marron CTA (site Web de CTA et de TransitFeeds)
Nom du champ Recommandation
trips.trip_id Le trajet "aller-retour" complet emprunté par un véhicule (voir l'illustration ci-dessus) consiste à aller du point A au point B, puis de retourner du point B au point A. Le trajet aller-retour complet emprunté par un véhicule peut être exprimé par les éléments suivants :
  • Une valeur/entrée trip_id unique dans trips.txt
  • Plusieurs valeurs/entrées trip_id dans trips.txt avec un voyage continu indiqué par block_id.
  • stop_times.stop_headsign Les véhicules passeront par les arrêts situés le long de la section entre le point A et le point B. stop_headsign permet de faire facilement la différence entre les sens de voyage. Nous vous recommandons dès lors de renseigner stop_headsign pour les trajets de ce type.
    Exemples :
    "A via B"
    "A"
    Ligne violette de la Chicago Transit Authority
    "Direction Sud vers Loop"
    "Direction Nord via Loop"
    "Direction Nord vers Linden"
    Lignes d'autobus du service de transports en commun d'Edmonton, ici la ligne 39
    "Rutherford"
    "Century Park"
    trip.trip_headsign Le texte affiché sur la girouette pour le trajet doit correspondre à une description globale de celui-ci, comme celle figurant dans les horaires. Ce texte peut être exprimé sous la forme "Linden vers Linden via Loop" (exemple de Chicago) ou "A vers A via B" (exemple générique).

    Branches

    Certains itinéraires peuvent inclure des branches. L'alignement et les arrêts sont partagés entre ces branches, mais chacune d'entre elles dessert également des arrêts et des sections d'alignement distincts. La relation entre les branches peut être indiquée par les noms des itinéraires, les girouettes et le nom court du trajet en suivant les instructions ci-dessous.

    Ci-dessous : trois configurations possibles de branches d'itinéraire. L'alignement principal est représenté en noir. La branche est représentée avec une couleur dorée.
    Configurations des branches d&#39;itinéraire
    Nom du champ Recommandation
    Tous les champs Lorsque vous attribuez un nom à des branches d'itinéraire, il est recommandé de suivre le même format que pour les autres informations communiquées aux usagers. Vous trouverez ci-dessous des descriptions et des exemples associés à deux cas :
    Si les horaires et les panneaux installés dans la rue sont associés à des itinéraires portant des noms différents (1A et 1B, par exemple), présentez-les de cette manière dans le flux GTFS en utilisant les champs route_short_name et/ou route_long_name. Par exemple : les itinéraires de transports en commun GoDurham 2, 2A et 2B partagent un alignement commun sur la majeure partie de l'itinéraire, mais plusieurs aspects les différencient.
    • L'itinéraire 2 représente le service principal, assuré à de nombreuses heures.
    • L'itinéraire 2 inclut une déviation sur Main Street le soir, le dimanche et les jours fériés.
    • Le service des itinéraires 2A et 2B est assuré en journée du lundi au samedi.
    • L'itinéraire 2B dessert des arrêts supplémentaires sur une déviation par rapport à l'alignement commun.
    Si les informations fournies par l'agence décrivent les branches comme l'itinéraire associé au même nom, utilisez les champs trips.trip_headsign, stop_times.stop_headsign et/ou trips.trip_short_name. Par exemple, l'itinéraire GoTriangle 300 passe par différents lieux en fonction de l'heure de la journée. Pendant les heures de pointe, des services supplémentaires sont assurés pour l'itinéraire standard afin de permettre aux travailleurs d'entrer dans la ville et d'en sortir.

    À propos de ce document

    Objectifs

    Les objectifs derrière les bonnes pratiques concernant le format GTFS sont les suivants :

    • Assurer une interopérabilité accrue des données des transports en commun
    • Améliorer l'expérience des utilisateurs finaux dans les applications de transports en commun
    • Permettre aux développeurs de logiciels de déployer et de faire évoluer plus facilement leurs applications, leurs produits et leurs services
    • Faciliter l'utilisation du format GTFS dans différentes catégories d'applications (au-delà de la planification de trajets, son objet initial)

    Proposer des modifications ou des ajouts aux bonnes pratiques concernant le format GTFS

    Les applications et les pratiques GTFS évoluent. Par conséquent, ce document devra peut-être faire l'objet de modifications de temps en temps. Pour proposer une modification du présent document, effectuez une demande d'extraction dans le répertoire GitHub dédié aux bonnes pratiques concernant le format GTFS et défendez la modification. Vous pouvez également envoyer des commentaires par e-mail à l'adresse specifications@mobilitydata.org.

    Faire référence à ce document

    Faites référence au présent document afin de fournir aux producteurs de flux des conseils visant à créer des données GTFS correctement. Chaque recommandation individuelle est associée à un lien d'ancrage. Cliquez sur la recommandation pour obtenir l'URL correspondant au lien d'ancrage de la page.

    Si une application qui a recours au GTFS effectue des demandes ou des recommandations en lien avec les bonnes pratiques concernant le format GTFS qui ne sont pas décrites ici, nous vous recommandons de publier un document avec ces exigences ou recommandations pour compléter ces bonnes pratiques courantes.

    Groupe de travail en charge des bonnes pratiques concernant le format GTFS

    Le groupe de travail en charge des bonnes pratiques concernant le format GTFS a été mis en place par le Rocky Mountain Institute en 2016-2017. Il regroupe des fournisseurs de services de transports publics, des développeurs d'applications ayant recours au GTFS, des consultants et des établissements scolaires. Ensemble, ils définissent des attentes et des pratiques courantes pour les données GTFS. Voici certains membres de ce groupe de travail :

    Aujourd'hui, ce document est géré par l'organisation internationale MobilityData.