Bonnes pratiques de GTFS Schedule¶
Il sâagit de pratiques recommandĂ©es pour dĂ©crire les services de transport public dans la General Transit Feed Specification (GTFS). Ces pratiques ont Ă©tĂ© synthĂ©tisĂ©es Ă partir de lâexpĂ©rience des membres du groupe de travail sur les bonnes pratiques GTFS et des bonnes pratiques GTFS pour les applications rĂ©utilisatrices.
Pour plus dâinformations, consultez la Foire aux questions.
Structure du document¶
Les pratiques sont organisées en quatre sections principales :
- Publication des jeux de données et pratiques générales : Ces pratiques concernent la structure globale du jeu de données GTFS et à la maniÚre dont les jeux de données GTFS sont publiés.
- Bonnes pratiques organisées par fichier : Les recommandations sont organisées par fichier et par champ dans le GTFS pour faciliter la correspondance des pratiques avec la référence officielle du GTFS.
- Bonnes pratiques organisĂ©es par cas : Dans des cas particuliers, tels que les itinĂ©raires en boucle, les pratiques peuvent devoir ĂȘtre appliquĂ©es Ă plusieurs fichiers et champs. Ces recommandations sont regroupĂ©es dans cette section.
Publication des jeux de donnĂ©es et pratiques gĂ©nĂ©rales¶
- Les jeux de donnĂ©es doivent ĂȘtre publiĂ©s sur une URL publique et permanente, y compris le nom du fichier zip. (par exemple, www.agence.org/gtfs/gtfs.zip). IdĂ©alement, lâURL devrait ĂȘtre directement tĂ©lĂ©chargeable sans nĂ©cessiter de connexion pour accĂ©der au fichier, afin de faciliter le tĂ©lĂ©chargement par les applications rĂ©utilisatrices. Bien quâil soit recommandĂ© (et constitue la pratique la plus courante) de rendre un ensemble de donnĂ©es GTFS librement tĂ©lĂ©chargeable, si un fournisseur de donnĂ©es doit contrĂŽler lâaccĂšs Ă GTFS pour des raisons de licence ou pour dâautres raisons, il est recommandĂ© de contrĂŽler lâaccĂšs au jeu de donnĂ©es GTFS Ă lâaide de clĂ©s API. ce qui facilitera les tĂ©lĂ©chargements automatiques.
- Les donnĂ©es GTFS sont publiĂ©es par itĂ©rations afin quâun seul fichier situĂ© Ă un emplacement stable contienne toujours la derniĂšre description officielle du service dâune ou plusieurs agences de transport en commun.
- Conserver des identifiants persistants (champs 'id') pour
stop_id
,route_id
etagency_id
Ă travers les itĂ©rations de donnĂ©es chaque fois que possible. - Un ensemble de donnĂ©es GTFS doit contenir le service actuel et Ă venir (parfois appelĂ© ensemble de donnĂ©es « fusionnĂ© »). La fonction de fusion peut ĂȘtre utilisĂ©e pour crĂ©er un ensemble de donnĂ©es fusionnĂ© Ă partir de deux flux GTFS diffĂ©rents.
- Ă tout moment, le jeu de donnĂ©es GTFS publiĂ© doit ĂȘtre valide pendant au moins les 7 prochains jours, et idĂ©alement aussi longtemps que lâopĂ©rateur est convaincu que lâhoraire continuera Ă ĂȘtre exploitĂ©.
- Si possible, le jeu de données GTFS doit couvrir au moins les 30 prochains jours de service.
- Supprimez les anciens services (calendriers expirés) du flux.
- Si une modification de service entre en vigueur dans 7 jours ou moins, exprimez cette modification de service via un flux GTFS Realtime (avis de service ou mises à jour de trajet) plutÎt qu'un jeu de données GTFS Schedule.
- Le serveur Web hĂ©bergeant les donnĂ©es GTFS doit ĂȘtre configurĂ© pour signaler correctement la date de modification du fichier (voir HTTP/1.1- Request for Comments 2616, en vertu de lâarticle 14.29).
Bonnes pratiques organisĂ©es par fichier¶
Cette section prĂ©sente les bonnes pratiques organisĂ©es par fichier et par champ, en sâalignant sur la rĂ©fĂ©rence GTFS.
Tous les fichiers¶
Nom du champ | Recommandation |
---|---|
Cas mixte | Toutes les chaĂźnes de texte destinĂ©es aux clients (y compris les noms dâarrĂȘts, les noms dâitinĂ©raires et les panneaux de signalisation) doivent utiliser une casse mixte (et non en MAJUSCULES), en suivant les conventions locales pour la mise en majuscule des noms de lieux sur les Ă©crans capables dâafficher des caractĂšres minuscules. |
Exemples : | |
Place Brighton Churchill | |
Villiers-sur-Marne | |
Boulevard du marché | |
AbrĂ©viations | Ăvitez dâutiliser des abrĂ©viations dans tout le flux pour les noms et autres textes (par exemple, bd pour boulevard), Ă moins quâun emplacement ne soit appelĂ© par son nom abrĂ©gĂ© (par exemple « AĂ©roport JFK »). Les abrĂ©viations peuvent poser problĂšme en termes dâaccessibilitĂ© par les logiciels de lecture dâĂ©cran et les interfaces utilisateur vocales. Une application rĂ©utilisatrice peut ĂȘtre conçue pour convertir de maniĂšre fiable des mots complets en abrĂ©viations Ă afficher, mais la conversion dâabrĂ©viations en mots complets est sujette Ă un plus grand risque dâerreur. |
agency.txt¶
Nom du champ | Recommandation |
---|---|
agency_phone |
Doit ĂȘtre inclus Ă moins quâaucun numĂ©ro de tĂ©lĂ©phone pour le service client nâexiste. |
agency_email |
Doit ĂȘtre inclus, sauf si aucun e-mail pour le service client nâexiste. |
agency_fare_url |
Doit ĂȘtre inclus, sauf si les services de l'agence sont totalement gratuits. |
Exemples :
-
Les services de bus sont gĂ©rĂ©s par plusieurs petites agences de bus. Mais il existe une grande agence qui est responsable de la planification et de la billetterie et, du point de vue de lâutilisateur, est responsable des services de bus. La grande agence doit ĂȘtre dĂ©finie comme une agence au sein du flux. MĂȘme si les donnĂ©es sont rĂ©parties en interne par diffĂ©rents petits opĂ©rateurs de bus, une seule agence doit ĂȘtre dĂ©finie dans le flux.
-
Le fournisseur de flux gĂšre le portail de billetterie, mais il existe diffĂ©rentes agences qui exploitent rĂ©ellement les services et dont les utilisateurs savent quâelles en sont responsables. Les agences qui exploitent rĂ©ellement les services doivent ĂȘtre dĂ©finies comme des agences au sein du flux.
stops.txt¶
Nom du champ | Recommandation | ||||||||
---|---|---|---|---|---|---|---|---|---|
stop_name |
Lorsquâaucun nom dâarrĂȘt nâest publiĂ©, suivez des conventions de dĂ©nomination dâarrĂȘt cohĂ©rentes dans tout le flux. | ||||||||
Par dĂ©faut, stop_name ne doit pas contenir de mots gĂ©nĂ©riques ou redondants comme « Station » ou « ArrĂȘt », mais certains cas extrĂȘmes sont autorisĂ©s.
|
|||||||||
stop_lat et stop_lon |
Les emplacements des arrĂȘts doivent ĂȘtre aussi prĂ©cis que possible. Une marge d'erreur de pas plus de quatre mĂštres est permise par rapport Ă la position dâarrĂȘt rĂ©elle. | ||||||||
Les arrĂȘts doivent ĂȘtre placĂ©s au plus prĂšs de l'endroit oĂč les passagers embarqueront (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 (câest-Ă -dire que deux agences utilisent exactement le mĂȘme arrĂȘt/installation dâembarquement), indiquez que lâarrĂȘt est partagĂ© en utilisant exactement les mĂȘmes stop_lat et stop_lon pour les deux arrĂȘts. |
|||||||||
parent_station & location_type |
De nombreuses gares ou terminaux disposent de plusieurs installations dâembarquement (selon le mode, elles peuvent ĂȘtre appelĂ©es quai de bus, quai, porte ou autre terme). Dans de tels cas, les producteurs de flux doivent dĂ©crire les gares, les installations dâembarquement (Ă©galement appelĂ©es sous-arrĂȘts) et leurs relations.
|
||||||||
Lorsque vous nommez la gare et les sous-arrĂȘts, dĂ©finissez des noms bien reconnus par les usagers et qui peuvent aider les usagers Ă identifier la gare et lâinstallation dâembarquement (quai de bus, quai, quai, porte, etc.).
|
routes.txt¶
Nom du champ | Recommandation | |||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
route_long_name |
La dĂ©finition de la rĂ©fĂ©rence: Ce nom est gĂ©nĂ©ralement plus descriptif que « . Au moins lâun des route_short_name ou route_long_name doit ĂȘtre spĂ©cifiĂ©, ou potentiellement les deux, le cas Ă©chĂ©ant. Si la route nâa pas de nom long, veuillez spĂ©cifier un route_short_name et utiliser une string vide comme valeur pour ce champ.Exemples de types de noms longs :
|
|||||||||||||||||
route_long_name ne doit pas contenir le route_short_name . |
||||||||||||||||||
Incluez la désignation complÚte, y compris une identité de service, lors du remplissage de route_long_name . Exemples:
|
||||||||||||||||||
route_id |
Tous les trajets sur un itinĂ©raire nommĂ© donnĂ© doivent faire rĂ©fĂ©rence au mĂȘme route_id .route_id .route_id (câest-Ă -dire 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 de routes comprend des branches nommées distinctement (par exemple 1A et 1B), suivez les recommandations dans le cas route branches pour déterminer route_short_name et route_long_name . |
||||||||||||||||||
route_color & route_text_color |
Doit ĂȘtre cohĂ©rent avec la signalisation et les informations client imprimĂ©es et en ligne (et donc non incluses si elles nâexistent pas ailleurs). |
trips.txt¶
- Voir cas particulier pour les itinĂ©raires en boucle : Les itinĂ©raires en boucle sont des cas oĂč les trajets commencent et se terminent au mĂȘme arrĂȘt, par opposition aux itinĂ©raires linĂ©aires, qui ont deux terminus distincts. Les itinĂ©raires en boucle doivent ĂȘtre dĂ©crits selon des pratiques spĂ©cifiques. Voir Cas dâitinĂ©raire en boucle.
- Voir cas particulier pour les itinĂ©raires en lasso : Les itinĂ©raires en lasso sont un hybride de gĂ©omĂ©tries linĂ©aires et en boucle, dans lesquelles les vĂ©hicules circulent en boucle sur une partie seulement de lâitinĂ©raire. Les itinĂ©raires du lasso doivent ĂȘtre dĂ©crits selon des pratiques spĂ©cifiques. Voir le cas de la route Lasso.
Nom du champ | Recommandation | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
trip_headsign |
Ne fournissez pas de noms dâitinĂ©raire (correspondant Ă route_short_name et route_long_name ) dans les champs trip_headsign ou stop_headsign . |
||||||||||||||
Doit contenir la destination, la direction et/ou tout autre texte de dĂ©signation de voyage indiquĂ© sur la girouette du vĂ©hicule qui peut ĂȘtre utilisĂ© pour distinguer les voyages sur un itinĂ©raire. La cohĂ©rence avec les informations de direction affichĂ©es sur le vĂ©hicule est lâobjectif principal et primordial pour dĂ©terminer les valeurs fournies dans les jeux de donnĂ©es GTFS. Dâautres informations ne doivent ĂȘtre incluses que si elles ne compromettent pas cet objectif principal. Si les girouettes changent au cours dâun voyage, remplacez trip_headsign par stop_times.stop_headsign . Vous trouverez ci-dessous des recommandations pour certains cas possibles : |
|||||||||||||||
|
|||||||||||||||
Ne commencez pas un bandeau par les mots « Vers » ou « Vers ». | |||||||||||||||
direction_id |
Utilisez les valeurs 0 et 1 de maniĂšre cohĂ©rente dans tout le jeu de donnĂ©es, câest Ă dire :
|
||||||||||||||
bikes_allowed |
Pour les voyages en ferry, soyez explicite sur le fait que les vélos sont autorisés (ou non), car éviter les voyages en ferry en raison de données manquantes entraßne généralement de grands détours. |
stop_times.txt¶
Itinéraires en boucle : les itinéraires en boucle nécessitent des considérations spéciales en matiÚre de stop_times
. (Voir : Cas dâitinĂ©raire en boucle)
Nom du champ | Recommandation | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
pickup_type et drop_off_type |
Les trajets "sans voyageur" qui ne fournissent pas de service aux passagers doivent ĂȘtre marquĂ©s avec pickup_type et drop_off_type dâune valeur de 1 pour toutes les lignes stop_times . |
||||||||||||
Pour les trajets qui prennent des passagers, les « points de synchronisation » internes qui servent Ă assurer le passage Ă l'heure prĂ©vue et dâautres endroits tels que les garages dans lesquels un passager ne peut pas monter Ă bord doivent ĂȘtre marquĂ©s avec pickup_type = 1 (pas de prise en charge disponible) et drop_off_type = 1 (pas de dĂ©pĂŽt disponible). |
|||||||||||||
arrival_time et departure_time |
Les champs arrival_time et departure_time doivent spécifier des valeurs de temps dans la mesure du possible, y compris des temps estimés ou interpolés non dépendants. |
||||||||||||
stop_headsign |
En gĂ©nĂ©ral, les valeurs des girouettes doivent Ă©galement correspondre aux panneaux prĂ©sents dans les gares. Dans les cas ci-dessous, « Southbound » induirait les clients en erreur car il nâest pas utilisĂ© dans les panneaux des gares. |
||||||||||||
|
|||||||||||||
|
calendar.txt¶
Nom du champ | Recommandation |
---|---|
Tous les champs | calendar.service_name peut augmenter la lisibilité humaine de GTFS, bien que cela ne soit pas adopté dans la spécification. |
calendar_dates.txt¶
Nom du champ | Recommandation |
---|---|
Tous les champs | calendar.service_name peut augmenter la lisibilité humaine de GTFS, bien que cela ne soit pas adopté dans la spécification. |
fare_attributes.txt¶
Nom du champ | Recommandation |
---|---|
Si un systĂšme tarifaire ne peut pas ĂȘtre modĂ©lisĂ© avec prĂ©cision, Ă©vitez toute confusion supplĂ©mentaire et laissez ce champ vide. | |
Incluez les tarifs (fare_attributes.txt et fare_rules.txt ) et modĂ©lisez-les aussi prĂ©cisĂ©ment que possible. Dans les cas extrĂȘmes oĂč les tarifs ne peuvent pas ĂȘtre modĂ©lisĂ©s avec prĂ©cision, le tarif doit ĂȘtre reprĂ©sentĂ© comme plus cher plutĂŽt que moins cher afin que les clients ne tentent pas dâembarquer avec un tarif insuffisant. 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 | Si un systĂšme tarifaire ne peut pas ĂȘtre modĂ©lisĂ© avec prĂ©cision, Ă©vitez toute confusion supplĂ©mentaire et laissez ce champ vide. |
Incluez les tarifs (fare_attributes.txt et fare_rules.txt ) et modĂ©lisez-les aussi prĂ©cisĂ©ment que possible. Dans les cas extrĂȘmes oĂč les tarifs ne peuvent pas ĂȘtre modĂ©lisĂ©s avec prĂ©cision, le tarif doit ĂȘtre reprĂ©sentĂ© comme plus cher plutĂŽt que moins cher afin que les clients ne tentent pas dâembarquer avec un tarif insuffisant. 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 tracĂ©s partagĂ©s (câest-Ă -dire dans le cas oĂč les Lignes 1 et 2 fonctionnent sur le mĂȘme segment de route ou de voie), la partie partagĂ©e du tracĂ© devrait correspondre exactement. Cela contribue Ă faciliter une cartographie des transports en commun de haute qualitĂ©. |
Les tracĂ©s partagĂ©s doivent suivre la ligne mĂ©diane de la route sur laquelle circule le vĂ©hicule. Il peut sâagir soit de la ligne centrale de la rue sâil nây a pas de voies dĂ©signĂ©es, soit de la ligne centrale du cĂŽtĂ© de la chaussĂ©e qui se dĂ©place dans la direction oĂč se dĂ©place le vĂ©hicule. Les tracĂ©s partagĂ©s ne doivent pas « sâĂ©loigner » dâun arrĂȘt de trottoir, dâun quai ou dâun emplacement dâembarquement. |
|
shape_dist_traveled |
Le champ shape_dist_traveled permet Ă lâagence de prĂ©ciser exactement comment les arrĂȘts du fichier stop_times.txt sâinscrivent dans leur forme respective. Une valeur courante Ă utiliser pour le champ shape_dist_traveled est la distance depuis le dĂ©but de la forme parcourue par le vĂ©hicule (pensez Ă quelque chose comme une lecture dâun compteur kilomĂ©trique).shapes.txt ) doivent se trouver Ă moins de 100 mĂštres des emplacements dâarrĂȘt desservis par un trajet.shapes.txt ne contienne pas de points superflus (câest-Ă -dire, supprimez les points supplĂ©mentaires sur les segments de ligne droite ; voir la discussion sur le problĂšme de simplification des lignes). |
frequencies.txt¶
Nom du champ | Recommandation |
---|---|
Tous les champs | Les horaires dâarrĂȘts rĂ©els sont ignorĂ©s pour les trajets rĂ©fĂ©rencĂ©s par frequencies.txt ; seuls les intervalles de temps de trajet entre les arrĂȘts sont significatifs pour les dĂ©placements basĂ©s sur la frĂ©quence. Pour plus de clartĂ© et de lisibilitĂ© humaine, il est recommandĂ© que la premiĂšre heure dâarrĂȘt dâun trajet rĂ©fĂ©rencĂ© dans frequencies.txt commence Ă 00:00:00 (premiĂšre valeur arrival_time de 00:00:00). |
block_id |
Peut ĂȘtre fourni pour des dĂ©placements basĂ©s sur la frĂ©quence. |
transfers.txt¶
transfers.transfer_type
peut ĂȘtre lâune des quatre valeurs dĂ©finies dans le GTFS. Ces dĂ©finitions de transfer_type
sont tirées de la spécification GTFS ci-dessous, avec des bonnes pratiques supplémentaires.
Nom du champ | Recommandation |
---|---|
transfer_type |
0 ou (vide) : Il sâagit dâun point de transfert recommandĂ© entre les itinĂ©raires. Sâil existe plusieurs possibilitĂ©s de transfert incluant une option supĂ©rieure (câest-Ă -dire un centre de transit dotĂ© de commoditĂ©s supplĂ©mentaires ou une gare avec des installations/plateformes dâembarquement adjacentes ou connectĂ©es), prĂ©cisez un point de transfert recommandĂ©. |
1 : Il sâagit dâun point de transfert chronomĂ©trĂ© entre deux itinĂ©raires. Le vĂ©hicule au dĂ©part doit attendre celui qui arrive, en laissant suffisamment de temps au passager pour effectuer le transfert entre les itinĂ©raires. Ce type de transfert remplace un intervalle requis pour effectuer des transferts de maniĂšre fiable. Ă titre dâexemple, Google Maps suppose que les passagers ont besoin de 3 minutes pour effectuer un transfert en toute sĂ©curitĂ©. Dâautres applications peuvent adopter dâautres valeurs par dĂ©faut. |
|
2 : Ce transfert nĂ©cessite un minimum de temps entre lâarrivĂ©e et le dĂ©part pour assurer une correspondance. Le temps requis pour le transfert est spĂ©cifiĂ© par SpĂ©cifiez le temps de transfert minimum sâil y a des obstacles ou dâautres facteurs qui augmentent le temps de trajet entre les arrĂȘts. |
|
3 : Les transferts ne sont pas possibles entre les itinĂ©raires Ă cet endroit. PrĂ©cisez cette valeur si les transferts ne sont pas possibles en raison dâobstacles physiques, ou sâils sont rendus dangereux ou compliquĂ©s par des passages Ă niveau difficiles ou des lacunes dans le rĂ©seau piĂ©tonnier. |
|
Si les transferts Ă bord (en bloc) sont autorisĂ©s entre les voyages, le dernier arrĂȘt du voyage Ă lâarrivĂ©e doit ĂȘtre le mĂȘme que le premier arrĂȘt du voyage au dĂ©part. |
Bonnes pratiques organisĂ©es par cas¶
Cette section couvre des cas particuliers ayant des implications dans plusieurs fichiers et champs.
Lignes en boucle¶
Sur les itinĂ©raires en boucle, les trajets des vĂ©hicules commencent et se terminent au mĂȘme endroit (parfois un centre de transit ou de transfert). Les vĂ©hicules fonctionnent gĂ©nĂ©ralement en continu et permettent aux passagers de rester Ă bord pendant que le vĂ©hicule poursuit sa boucle.
Les recommandations des girouettes doivent donc ĂȘtre appliquĂ©es afin dâindiquer aux usagers la direction dans laquelle va le vĂ©hicule.
Pour indiquer le changement de direction de déplacement, fournissez stop_headsigns
dans le fichier stop_times.txt
. Le stop_headsign
dĂ©crit la direction des trajets au dĂ©part de lâarrĂȘt pour lequel il est dĂ©fini. Lâajout de stop_headsigns
Ă chaque arrĂȘt dâun voyage vous permet de modifier les informations de la girouette tout au long du voyage.
Ne dĂ©finissez pas un seul trajet circulaire dans le fichier stop_times.txt pour un itinĂ©raire qui fonctionne entre deux points dâarrivĂ©e (par exemple lorsque le mĂȘme bus fait lâaller et le retour). Au lieu de cela, divisez le voyage en deux directions distinctes.
Exemples de modélisation de trajet circulaire :
- Trajet circulaire avec changement de 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 | "" |
- Voyage circulaire avec deux girouettes
trip_id | arrival_time | departure_time | stop_id | stop_sequence | stop_headsign |
---|---|---|---|---|---|
trip_1 | 06:10:00 | 06:10:00 | stop_A | 1 | "sortant" |
trip_1 | 06:15:00 | 06:15:00 | stop_B | 2 | "sortant" |
trip_1 | 06:20:00 | 06:20:00 | stop_C | 3 | "sortant" |
trip_1 | 06:25:00 | 06:25:00 | stop_D | 4 | "entrant" |
trip_1 | 06:30:00 | 06:30:00 | stop_E | 5 | "entrant" |
trip_1 | 06:35:00 | 06:35:00 | stop_F | 6 | "entrant" |
trip_1 | 06:40:00 | 06:40:00 | stop_A | 7 | "" |
Nom du champ | Recommandation | |||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
voyages.trip_id |
ModĂ©lisez lâaller-retour complet de la boucle avec un seul trajet. | |||||||||||||||
stop_times.stop_id |
Incluez le premier/dernier arrĂȘt deux fois dans stop_times.txt pour le trajet qui est une boucle. Exemple ci-dessous. Souvent, un itinĂ©raire en boucle peut inclure un premier et un dernier trajet qui ne parcourent pas la totalitĂ© de la boucle. Incluez Ă©galement ces voyages.
|
|||||||||||||||
trips.direction_id |
Si la boucle fonctionne dans des directions opposĂ©es (câest-Ă -dire dans le sens horaire et antihoraire), alors dĂ©signez direction_id comme 0 ou 1 . |
|||||||||||||||
trips.block_id |
Indiquez les dĂ©placements en boucle continue avec le mĂȘme block_id . |
Lignes Lasso¶
Les itinĂ©raires Lasso combinent les aspects dâun itinĂ©raire en boucle et dâun itinĂ©raire directionnel.
Exemples : |
---|
Lignes de métro (Chicago) |
Lignes de bus de la banlieue au centre-ville (St. Albert ou Edmonton) |
Ligne marron du CTA (Site Web du CTA et TransitFeeds) |
Nom du champ | Recommandation | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
trips.trip_id |
LâĂ©tendue complĂšte dâun « aller-retour de vĂ©hicule » (voir lâillustration ci-dessus) consiste en un voyage de A Ă B Ă B et retour Ă A. Un aller-retour complet de vĂ©hicule peut ĂȘtre exprimĂ© par :trip_id dans trips.txt trip_id dans trips.txt , avec un dĂ©placement continu indiquĂ© par block_id . |
||||||||||
stop_times.stop_headsign |
Les arrĂȘts le long du tronçon AB seront traversĂ©s dans les deux sens. stop_headsign facilite la distinction de la direction du dĂ©placement. Par consĂ©quent, il est recommandĂ© de fournir stop_headsign pour ces trajets.
|
||||||||||
trip.trip_headsign |
Le trip_headsign doit ĂȘtre une description globale du voyage, telle quâelle apparaĂźt dans les horaires. Cela pourrait ĂȘtre « Linden to Linden via Loop » (exemple de Chicago) ou « A to A via B » (exemple gĂ©nĂ©rique). |
Branches¶
Certains itinĂ©raires peuvent inclure des branches. Les tracĂ©s et les arrĂȘts sont partagĂ©s entre ces branches, mais chacune dessert Ă©galement des arrĂȘts et des sections de tracĂ© distinctes. La relation entre les branches peut ĂȘtre indiquĂ©e par le(s) nom(s) dâitinĂ©raire, les girouettes et le nom abrĂ©gĂ© du trajet en utilisant les directives supplĂ©mentaires ci-dessous.
Nom du champ | Recommandation |
---|---|
Tous les champs | Lors de la dĂ©nomination des itinĂ©raires secondaires, il est recommandĂ© de suivre dâautres documents dâinformation pour les passagers. Vous trouverez ci-dessous des descriptions et des exemples de deux cas : |
Si les horaires et la signalisation sur rue reprĂ©sentent deux itinĂ©raires nommĂ©s distinctement (par exemple 1A et 1B), prĂ©sentez-les comme tels dans le GTFS, en utilisant le route_short_name et/ou champs route_long_name . Exemple : GoDurham Transit itinĂ©raires 2, 2A et 2B partagent un tracĂ© commun sur la majoritĂ© de lâitinĂ©raire, mais ils varient sous plusieurs aspects diffĂ©rents.
|
|
Si les informations fournies par lâagence dĂ©crivent les branches avec le mĂȘme nom d'itinĂ©raire, utilisez les champs trips.trip_headsign , stop_times.stop_headsign et/ou trips.trip_short_name . Exemple : GoTriangle route 300 se dĂ©place vers diffĂ©rents endroits en fonction de lâheure de la journĂ©e. Pendant les heures de pointe, des trajets supplĂ©mentaires sont ajoutĂ©s Ă lâitinĂ©raire standard pour accueillir les travailleurs entrant et sortant de la ville. |
Foire aux questions (FAQ)¶
Pourquoi ces bonnes pratiques GTFS sont-elles importantes ?¶
Les objectifs des bonnes pratiques GTFS sont :
- AmĂ©liorer lâexpĂ©rience client de lâutilisateur final dans les applications de transports publics
- Prendre en charge une large interopérabilité des données pour permettre aux développeurs de logiciels de déployer et de faire évoluer plus facilement des applications, des produits, et services
- Faciliter lâutilisation de GTFS dans diverses catĂ©gories dâapplications (au-delĂ de son objectif initial sur la planification de voyage)
Sans bonnes pratiques GTFS coordonnées, diverses applications consommatrices de GTFS peuvent établir des exigences et des attentes de maniÚre non coordonnée, ce qui conduit à des exigences divergentes et à des jeux de données spécifiques aux applications et à une interopérabilité moindre. Avant la publication des bonnes pratiques, il y avait une plus grande ambiguïté et un plus grand désaccord sur ce qui constitue des données GTFS correctement formées.
Comment ont-elles Ă©tĂ© Ă©laborĂ©es ? Qui les a dĂ©veloppĂ©es ?¶
Ces bonnes pratiques ont Ă©tĂ© dĂ©veloppĂ©es par un groupe de travail de 17 organisations impliquĂ©es dans GTFS, y compris des fournisseurs dâapplications et des consommateurs de donnĂ©es, des fournisseurs de transport en commun et des consultants largement impliquĂ©s dans GTFS. Le groupe de travail a Ă©tĂ© convoquĂ© et animĂ© par le Rocky Mountain Institute.
Les membres du groupe de travail ont votĂ© sur chaque bonne pratique. 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 grande majoritĂ© dâorganisations.
Pourquoi ne pas simplement changer la rĂ©fĂ©rence GTFS ?¶
Bonne question ! Le processus dâexamen de la spĂ©cification, de lâutilisation des donnĂ©es et des besoins a en effet dĂ©clenchĂ© certaines modifications de la spĂ©cification (voir Pull Requests fermĂ©es dans GitHub). Les modifications de la rĂ©fĂ©rence GTFS sont soumises Ă un niveau dâexamen et de commentaires plus Ă©levĂ© que les bonnes pratiques. Certaines bonnes pratiques sont mergĂ©es dans la spĂ©cification en fonction de leur niveau dâadoption et du consensus communautaire. Ă terme, toutes les bonnes pratiques GTFS pourraient faire partie de la rĂ©fĂ©rence principale GTFS.
Comment vĂ©rifier la conformitĂ© Ă ces bonnes pratiques ?¶
Le validateur de GTFS Schedule canonique vérifie la conformité par rapport à ces bonnes pratiques. Vous pouvez en savoir plus sur cet outil de validation sur la page de validation.
Je reprĂ©sente une agence de transport. Quelles mesures puis-je prendre pour que nos fournisseurs de services logiciels suivent ces bonnes pratiques ?¶
RĂ©fĂ©rez votre fournisseur de services logiciels Ă ces bonnes pratiques. Nous vous recommandons de rĂ©fĂ©rencer lâURL des bonnes pratiques GTFS, ainsi que la rĂ©fĂ©rence de GTFS de base lors de lâachat de logiciels produisant du GTFS.
Que dois-je faire si je remarque quâun flux de donnĂ©es GTFS nâest pas conforme Ă ces bonnes pratiques ?¶
Cherchez le point de contact du flux dans les champs feed_contact_email ou feed_contact_url dans * feed_info.txt* sâils existent, ou en recherchant les coordonnĂ©es sur le site Web de lâagence de transport ou du producteur de flux. Lorsque vous communiquez le problĂšme au producteur de flux, fournissez le lien vers la bonne pratique GTFS spĂ©cifique. (Voir "Lien vers ce document").
Comment mâimpliquer ?¶
E-mail specifications@mobilitydata.org.
Ă propos de ce document¶
Objectifs¶
Les objectifs du maintien des bonnes pratiques GTFS sont les suivants :
- Prendre en charge une plus grande interopérabilité des données de transit
- Améliorer l'expérience cliente dans les applications de transports publics
- Faciliter le dĂ©ploiement et la mise Ă lâĂ©chelle des applications, des produits et des services pour les dĂ©veloppeurs de logiciels
- Faciliter lâutilisation de GTFS dans diverses catĂ©gories dâapplications (au-delĂ de son objectif initial sur la planification de voyage)
Comment proposer ou modifier les bonnes pratiques GTFS publiĂ©es¶
Les bonnes pratiques sont en cours de merge dans la spécification. Si vous souhaitez suggérer une nouvelle bonne pratique, veuillez accéder au répertoire GitHub de référence GTFS pour ouvrir une issue ou créer une Pull Request, ou contacter specifications@mobilitydata.org.
Lien vers ce document¶
Veuillez crĂ©er un lien vers cette page afin de fournir aux producteurs de flux des conseils pour la production correcte des donnĂ©es GTFS. Chaque recommandation individuelle a un lien dâancrage. Cliquez sur la recommandation pour obtenir lâURL du lien dâancrage dans la page.
Si une application consommant du GTFS formule des exigences ou des recommandations concernant les pratiques en matiÚre de données GTFS qui ne sont pas décrites ici, il est recommandé de publier un document contenant ces exigences ou recommandations pour compléter ces bonnes pratiques communes.
Groupe de travail sur les bonnes pratiques GTFS¶
Le groupe de travail sur les bonnes pratiques GTFS a Ă©tĂ© convoquĂ© par le Rocky Mountain Institute en 2016-2017, composĂ© de fournisseurs de transports publics, dĂ©veloppeurs dâapplications consommant du GTFS, consultants et organisations universitaires pour dĂ©finir des pratiques et des attentes communes concernant les donnĂ©es GTFS. Les membres de ce groupe de travail comprenaient :
- Cambridge Systematics
- Capital Metro
- Centre de recherche sur les transports urbains de lâUniversitĂ© de Floride du Sud
- Conveyal
- Groupe IBI
- Mapzen
- Microsoft
- Moovel
- DĂ©partement des transports de lâOregon
- Swiftly
- Transit
- Trillium
- TriMet
- Banque mondiale
Aujourdâhui, ce document est maintenu par MobilityData.