Aller au contenu

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

  • 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 et agency_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.
  • Lorsqu’il fait rĂ©ellement partie du nom (Union Station, Central Station)
  • Lorsque le stop_name est trop gĂ©nĂ©rique (par exemple s’il s’agit du nom de la ville). « Station », « Terminal » ou d’autres termes clarifient le nom de l'arrĂȘt.
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.
  • La station ou le terminal doit ĂȘtre dĂ©fini comme une entrĂ©e dans 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 au stop_id de la gare dans laquelle se trouve l’établissement d’embarquement.
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.).
Nom de la station principaleNom du sous-arrĂȘt
Gare Union de ChicagoQuai 19 de la gare Union de Chicago
Terminal du ferry de San FranciscoPorte E du terminal du ferry de San Francisco
Centre de transport en commun du centre-villeCentre de transport en commun du centre-ville, baie B

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 « route_short_name » et inclut souvent la destination ou l’arrĂȘt de l’itinĂ©raire. 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 :
Nom de l’itinĂ©raire FormatAgence
«N»/«Judah»route_short_name/
route_long_name
Muni, Ă  San Francisco
«6»/«Boulevard ML King Jr»route_short_name/
route_long_name
TriMet, Ă  Portland, Oregon.
«6»/«Nation-Étoile»route_short_name/
route_long_name
RATP, Ă  Paris France.
«U2»-«Pankow–Ruhleben»route_short_name-
route_long_name
BVG, Ă  Berlin, Allemagne
Description du service
«Navette de la région de Hartwell»
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:
Identité du service RecommandationExemples
«MAX Light Rail»
TriMet, Ă  Portland, Oregon
Le 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, Ă  Albuquerque, Nouveau-Mexique
Le 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 sur un itinĂ©raire nommĂ© donnĂ© doivent faire rĂ©fĂ©rence au mĂȘme route_id.
  • Les diffĂ©rentes directions d’un itinĂ©raire ne doivent pas ĂȘtre sĂ©parĂ©es en diffĂ©rentes valeurs route_id .
  • Les diffĂ©rentes pĂ©riodes d’exploitation d’une route ne doivent pas ĂȘtre sĂ©parĂ©es en diffĂ©rentes valeurs 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 :
    Description de l’itinĂ©raire Recommandation
    2A. Destination uniquement Indiquez la destination du terminus, par exemple "Transit Center", "Portland City Center" ou "Jantzen Beach".
    2B. Destinations avec points de passage <destination> via <point de passage>, par exemple « Highgate via Charing Cross ». Si des points de passage sont supprimés de la girouette affichée aux passagers une fois que le véhicule a dépassé ces points de passage, utilisez stop_times.stop_headsign pour définir une girouette mise à jour.
    2C. Nom de lieu rĂ©gional avec arrĂȘts locaux S’il y a 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 Indiquez-le en utilisant des termes tels que « vers le nord », « entrant », « dans le sens des aiguilles d’une montre » ou des directions similaires.
    2E. Direction avec destination <direction> vers <destination>, par exemple « En direction sud vers San Jose ».
    2F. Direction avec destination et points de passage <direction> via <point de passage> jusqu’à <destination>, par exemple « En direction nord via Charing Cross jusqu’à Highgate ».
    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 :
    • Si 1 = sortant sur l’itinĂ©raire rouge, alors 1 = sortant sur l’itinĂ©raire vert
    • Si 1 = en direction nord sur la route X, alors 1 = en direction nord sur la route Y
    • Si 1 = dans le sens des aiguilles d’une montre sur la route X alors 1 = dans le sens des aiguilles d’une montre sur la route Y
    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.
    À New York, pour les 2 en direction sud :
    Pour les entrées stop_times.txt : Utilisez la valeur stop_headsign :
    Jusqu’à ce que Manhattan soit atteint Manhattan & Brooklyn
    Jusqu’à ce que le centre-ville soit atteint Downtown & Brooklyn
    Jusqu’à ce que Brooklyn soit atteint Brooklyn
    Une fois Brooklyn atteint Brooklyn (New Lots Av)
    À Boston, pour la ligne rouge en direction sud, pour l’agence Braintree :
    Pour les entrées stop_times.txt : Utilisez la valeur stop_headsign :
    Jusqu’à ce que le centre-ville soit atteint Inbound to Braintree
    Une fois le centre-ville atteint Braintree
    AprĂšs le centre-ville Outbound to Braintree

    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).
  • Les tracĂ©s d’itinĂ©raires (dans shapes.txt) doivent se trouver Ă  moins de 100 mĂštres des emplacements d’arrĂȘt desservis par un trajet.
  • Simplifiez les alignements afin que 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 min_transfer_time .
    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.
    trip_id stop_id stop_sequence
    9000 101 1
    9000 102 2
    9000 103 3
    9000 101 4
    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 :
  • Une seule valeur/entrĂ©e trip_id dans trips.txt
  • Plusieurs valeurs/entrĂ©es 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.
    Exemples:
    "A via B"
    "A"
    Ligne violette de la Chicago Transit Authority
    "En direction sud vers la boucle"
    "En direction nord via la boucle"
    "En direction nord vers Linden"
    Lignes de bus du service de transport en commun d’Edmonton, ici le 39
    "Rutherford"
    "Century Park"
    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.
    • La route 2 est un service de base, fonctionnant la plupart des heures.
    • L’itinĂ©raire 2 comprend une dĂ©viation la nuit, les dimanches et les jours fĂ©riĂ©s de la rue Principale.
    • Les Lignes 2A et 2B fonctionnent pendant la journĂ©e du lundi au samedi.
    • La route 2B dessert des arrĂȘts supplĂ©mentaires dans une dĂ©viation du tracĂ© partagĂ©.
    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 :

    Aujourd’hui, ce document est maintenu par MobilityData.