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 :
- Bonnes pratiques générales et concernant la publication d'ensembles de données : Ces bonnes pratiques concernent la structure générale de l'ensemble de données GTFS et la manière dont les ensembles de données GTFS sont publiés.
- Recommandations liées aux bonnes pratiques organisées par fichier : Les recommandations sont organisées par fichier et par champ dans la norme GTFS pour faciliter la mise en correspondance des pratiques avec la référence GTFS officielle.
- Recommandations liées aux bonnes pratiques organisées par cas : Dans des cas particuliers (les itinéraires en boucle, par exemple), certaines pratiques doivent parfois être observées pour plusieurs fichiers et champs. Cette section regroupe les recommandations en question.
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, les différentes applications qui l'utilisent risquent d'établir des exigences et des attentes de manière non coordonnée. Cela peut donner lieu à des divergences dans les exigences et les ensembles de données spécifiques à chaque application et limiter 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 le respect de ces bonnes pratiques ?
Actuellement, aucun outil de validation ne vérifie le respect de toutes les bonnes pratiques. 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.
|
| 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 en temps réel (conseils de service ou informations sur les 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 n'incluent aucuns frais. |
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 stop_id pour des arrêts identiques dans les itérations de données (consultez la section 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.
|
|||||||||
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.
|
||||||||
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.).
|
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 Voici des exemples de types de noms longs :
|
||||||||||||||||||||
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 :
|
|||||||||||||||||||||
route_id |
Tous les trajets d'un itinéraire donné doivent faire référence au même route_id.
|
||||||||||||||||||||
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 déterminer 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 :
|
|||||||||||||||
| 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 :
|
stop_times.txt
Itinéraires en boucle : pour les itinéraires en boucle, il est nécessaire de porter une attention particulière aux 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
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. |
||||||||||||
|
|||||||||||||
|
|||||||||||||
| 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 
Si un véhicule retrace ou traverse l'alignement de l'itinéraire à certains points d'un trajet, |
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).
|
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 |
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é. |
Chaque utilisateur des données doit calculer la durée nécessaire pour cet intervalle à l'aide de son propre algorithme. Si cette valeur est insuffisante ou que l'utilisateur n'a pas pris en compte d'autres conditions, vous pouvez ignorer les calculs de temps après avoir défini le |
|
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. |
|
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.
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.
|
|||||||||||||||
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.
- Section directe du point A au point B
- Boucle depuis et vers le point B
- Section directe du point B au point A
| 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, de revenir au point B, avant de retourner au point A. Le trajet aller-retour complet emprunté par un véhicule peut être exprimé par les éléments suivants :
trip_id unique dans trips.txttrip_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.
|
||||||||||
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.
| 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.
|
|
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 :
- Cambridge Systematics
- Capital Metro
- Center for Urban Transportation Research de l'université de Floride du Sud
- Conveyal
- IBI Group
- Mapzen
- Microsoft
- Moovel
- Oregon Department of Transportation
- Swiftly
- Transit
- Trillium
- TriMet
- La Banque mondiale
Aujourd'hui, ce document est géré par l'organisation internationale MobilityData.