Meilleures pratiques pour 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 meilleures pratiques GTFS et des recommandations de pratiques GTFS spécifiques aux applications.

Pour plus d'informations, voir la Foire aux questions.

Structure du document¶

Les pratiques sont organisées en quatre sections principales :

Publication de 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.
Recommandations de pratiques organisées par fichier: Les recommandations sont organisées par fichier et par champ dans le GTFS afin de faciliter la mise en correspondance des pratiques avec la référence officielle du GTFS.
Recommandations pratiques organisées par cas: Dans certains cas particuliers, tels que les itinéraires en boucle, les pratiques peuvent devoir être appliquées dans plusieurs fichiers et champs. Ces recommandations sont regroupées dans cette section.

Publication des données et pratiques générales¶

Les ensembles de données devraient être publiés à une URL publique et permanente, incluant le nom du fichier zip. (par exemple, www.agency.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 logicielles consommatrices. Bien qu'il soit recommandé (et la pratique la plus courante) de rendre un jeu 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 autres, il est recommandé de contrôler l'accès au jeu de données GTFS en utilisant des clés API, ce qui facilitera les téléchargements automatiques.
Les donnéesGTFS sont publiées par itérations de sorte qu'un seul fichier à un emplacement stable contient toujours la dernière description officielle du service pour une ou plusieurs agences de transport en commun.
Dans la mesure du possible, maintenez des identifiants persistants (champs id) pour les champs stop_id, route_id et agency_id entre les itérations de données.
Un jeu de données GTFS devrait contenir le service actuel et le service à venir (parfois appelé jeu de données "fusionné"). La fonction de fusion de l'outil Google transitfeed peut être utilisée pour créer un jeu de données fusionné à partir de deux flux GTFS différents.
À tout moment, le jeu de données GTFS publié devrait être valable pour au moins les 7 prochains jours, et idéalement aussi longtemps que l'opérateur est sûr que l'horaire continuera à être exploité.
Si possible, le jeu de données GTFS devrait couvrir au moins les 30 prochains jours de service.
Supprimez les anciens services (calendriers expirés) du flux.
Si une modification de service doit entrer en vigueur dans 7 jours ou moins, exprimez ce changement de service par un flux GTFS-realtime (avis de service ou mises à jour des trajets) plutôt que par un jeu de données GTFS statique.
Le serveur web hébergeant les données GTFS devrait être configuré pour rapporter correctement la date de modification du fichier (voir HTTP/1.1 - Request for Comments 2616, sous la section 14.29).

Recommandations de pratiques organisées par fichier¶

Cette section présente les 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 mixtes	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 indicateurs) devraient utiliser la casse mixte (et non les MAJUSCULES), conformément aux conventions locales relatives à la capitalisation des noms de lieux sur les écrans capables d'afficher des caractères minuscules.
	Exemples :
	Brighton Churchill Square
	Villiers-sur-Marne
	Rue du Marché
Abréviations	Évitez l'utilisation d'abréviations dans l'ensemble du fil pour les noms et autres textes (par exemple, St. pour Street), sauf si un lieu est appelé par son nom abrégé (par exemple, "Aéroport JFK"). Les abréviations peuvent poser des problèmes d'accessibilité pour les logiciels de lecture d'écran et les interfaces utilisateur vocales. Les logiciels consommateurs peuvent être conçus pour convertir de manière fiable les mots complets en abréviations pour l'affichage, mais la conversion des abréviations en mots complets est sujette à un plus grand risque d'erreur.

agency.txt¶

Nom du champ	Recommandation
`agency_id`	Devrait être inclus, même s'il n'y a qu'une seule agence dans le flux. (Voir aussi la recommandation d'inclure `agency_id` sur `routes.txt` et `fare_attributes.txt`)
`agency_phone`	Devrait être inclus, sauf s'il n'existe pas de téléphone de service à la clientèle.
`agency_email`	Devrait être inclus sauf s'il n'existe pas de courriel du service à la clientèle.
`agency_fare_url`	Devrait être inclus sauf si l'agence est entièrement gratuite.

Exemples :

Les services de bus sont gérés par plusieurs petites agences de bus. Mais il y a une grande agence qui est responsable de la programmation et de la billetterie et qui, du point de vue de l'utilisateur, est responsable des services de bus. Même si les données sont divisées en interne par différents petits opérateurs de bus, il ne devrait y avoir qu'une seule agence définie dans le flux.
Le fournisseur de flux gère le portail de billetterie, mais différentes agences exploitent réellement les services et sont connues des utilisateurs pour être responsables. Les agences qui exploitent réellement les services devraient être définies comme des agences dans le flux.

stops.txt¶

Nom du champ Recommandation

stop_name Lorsqu'il n'y a pas de nom d'arrêt publié, suivez les conventions de dénomination des arrêts tout au long du flux.

Par défaut, stop_name ne devrait pas contenir de mots génériques ou redondants comme "Station" ou "Stop", mais certains cas limites sont autorisés.

Lorsqu'il fait partie du nom (Union Station, Central Station, etc.).
Lorsque le mot stop_name est trop générique (par exemple, s'il s'agit du nom de la ville). "Station", "Terminal", ou d'autres mots rendent le sens clair.

stop_lat & stop_lon Les emplacements des arrêts devraient être aussi précis que possible. Les arrêts devraient avoir une erreur de pas plus de quatre mètres par rapport à la position réelle de l'arrêt.

Les emplacements d'arrêt devraient être placés très près du droit de passage des piétons où un passager montera (c'est-à-dire du bon côté de la rue).

Si un emplacement d'arrêt est partagé par plusieurs sources de données (c'est-à-dire que deux agences utilisent exactement le même arrêt ou la même installation d'embarquement), indiquez qu'il s'agit d'un arrêt partagé en utilisant exactement le même numéro d'arrêt. 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 baie de bus, plate-forme, quai, porte, ou un autre terme). Dans ce cas, les producteurs de flux devraient décrire les stations, les installations d'embarquement (également appelées arrêts enfants) et leur relation.

La station ou le terminal devrait être défini comme un enregistrement dans la base de données de l'entreprise. stops.txt avec location_type = 1.
Chaque installation d'embarquement devrait être définie comme un arrêt avec un champ location_type = 0. Le site parent_station Le champ devrait faire référence au stop_id de la station dans laquelle se trouve la station d'embarquement.

Lorsque vous nommez la station et les arrêts enfants, choisissez des noms qui sont bien connus des usagers et qui peuvent les aider à identifier la station et l'installation d'embarquement (quai de bus, plate-forme, quai, porte, etc.).

Nom de la station mère	Nom de l'arrêt enfant
Chicago Union Station	Quai 19 de la gare Union de Chicago
San Francisco Ferry Building Terminal	Terminal du bâtiment des ferries de San Francisco Porte E
Centre de transit du centre-ville	Centre de transit du centre-ville, baie B

routes.txt¶

Nom du champ Recommandation

agency_id Devrait être inclus, même s'il n'y a qu'une seule agence dans le flux. (Voir aussi la recommandation d'inclure agency_id sur agency.txt et fare_attributes.txt)

route_short_name Inclure route_short_name s'il existe une brève désignation du service. Il devrait s'agir du nom communément utilisé par les passagers pour désigner le service, et ne devrait pas comporter plus de 12 caractères.

route_long_name

La définition de la référence de la spécification : Ce nom est généralement plus descriptif que le nom route_short_name et inclut souvent la destination ou l'arrêt de l'itinéraire. Au moins un des éléments suivants nom_courte_route ou route_long_name doit être spécifié, ou potentiellement les deux si nécessaire. Si l'itinéraire n'a pas de nom long, veuillez spécifier un nom_courte_route et utilisez une chaîne vide comme valeur pour ce champ.
Vous trouverez ci-dessous des exemples de types de noms longs :

Voie de déplacement principale ou couloir
Nom de l'itinéraire	Forme	Agence
"N"/"Judah"	`nom_courte_route`/ `route_long_name`	Muni à San Francisco
"6"/"ML King Jr Blvd"	`nom_courte_route`/ `route_long_name`	TriMet à Portland, Oregon
"6"/"Nation - Étoile"	`nom_courant`/ `nom_long_trajet`	RATP à Paris, France
"U2" - "Pankow" - "Ruhleben"	`nom_courte_route`- `nom_long_trajet`	BVG à Berlin, Allemagne

Description du service
"Navette de la région de Hartwell"

route_long_name ne devrait pas contenir la route_short_name.

Inclure la désignation complète, y compris l'identité du service, lors de l'inscription. route_long_name. Exemples :

Identité de service	Recommandation	Exemples :
"MAX Light Rail TriMet, à Portland, Oregon	Le site `nom_de_l'itinéraire` devrait 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 `nom_long_route` devrait inclure la marque (Rapid Ride) et la désignation spécifique de l'itinéraire.	"Ligne rouge de Rapid Ride "Rapid Ride Blue Line

route_id Tous les trajets d'un itinéraire donné devraient être référencés de la même manière. route_id.
Les différentes directions d'un itinéraire ne devraient pas être séparées en plusieurs itinéraires différents. route_id valeurs.
Les différentes périodes d'exploitation d'un itinéraire ne devraient pas être séparées en différentes valeurs. route_id différentes, c'est-à-dire qu'il ne faut pas créer des enregistrements différents en routes.txt pour les services "Downtown AM" et "Downtown PM").

Si un groupe d'itinéraires comprend des branches aux noms distincts (par exemple, 1A et 1B), suivez les recommandations de l'itinéraire branches cas pour déterminer route_short_name et route_long_name.

route_color & route_text_color Devrait être cohérent avec la signalisation et les informations imprimées et en ligne destinées aux clients (et donc ne pas être inclus s'ils n'existent pas à d'autres endroits).

trips.txt¶

Voir le cas particulier des 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 le cas des itinéraires en boucle.
Voir le cas particulier des itinéraires lasso : Les itinéraires lasso sont un hybride des géométries linéaire et en boucle, dans lequel les véhicules circulent sur une boucle sur une partie seulement de l'itinéraire. Les routes lasso doivent être décrites selon des pratiques spécifiques. Voir le cas de l'itinéraire Lasso.

Nom du champ Recommandation

trip_headsign Ne pas fournir de noms d'itinéraires (correspondant route_short_name et route_long_name) dans le trip_headsign ou stop_headsign champs.

Devrait contenir la destination, la direction et/ou tout autre texte de désignation du trajet figurant sur l'indicateur de direction du véhicule, qui peut être utilisé pour distinguer les trajets d'un itinéraire. La cohérence avec les informations de direction indiquées sur le véhicule est l'objectif principal et primordial pour déterminer les plaques frontales fournies dans les ensembles de données GTFS. D'autres informations ne devraient être incluses que si elles ne compromettent pas cet objectif principal. Si les panneaux d'indication changent au cours d'un trajet, il faut remplacer les panneaux d'indication de direction par des panneaux d'indication de direction. trip_headsign avec 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 finale, par exemple "Transit Center", "Portland City Center" ou "Jantzen Beach">.
2B. Destinations avec points de repère	via " Highgate via Charing Cross". Si le ou les points de passage sont supprimés de l'indicateur de direction affiché aux passagers après que le véhicule a franchi ces points de passage, utilisez l'option `stop_times.stop_headsign` pour définir un indicateur de direction actualisé.
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 seulement	Indiquez le nom en utilisant des termes tels que "Northbound", "Inbound", "Clockwise" ou des directions similaires.
2E. Direction avec destination	par exemple "Southbound to San Jose">.
2F. Direction avec destination et points de repère	via to ( "Northbound via Charing Cross to Highgate").>

Ne commencez pas un signe de direction par les mots "To" ou "Towards".

direction_id

Utilisez les valeurs 0 et 1 de manière cohérente dans l'ensemble de données.

Si 1 = sortie sur la route rouge, alors 1 = sortie sur la route verte.
Si 1 = en direction du nord sur la route X, alors 1 = en direction du nord sur la route Y.
Si 1 = sens horaire sur la route X, alors 1 = sens horaire sur la route Y.

stop_times.txt¶

Itinéraires en boucle : Les itinéraires en boucle requièrent des considérations spéciales sur les temps d'arrêt. (Voir : Cas des itinéraires en boucle)

Nom du champ Recommandation

pickup_type & drop_off_type Les trajets non rentables (deadhead) qui ne fournissent pas de service aux passagers devraient être marqués de la manière suivante pickup_type et drop_off_type valeur de 1 pour toutes les stop_times rangs.

Sur les trajets payants, les " points de synchronisation " internes pour le contrôle des performances opérationnelles et d'autres endroits, tels que les garages, où un passager ne peut pas monter, devraient être marqués de la valeur de pickup_type = 1 (pas de prise en charge possible) et drop_off_type = 1 (pas de dépose possible).

timepoint Le champ timepoint devrait être fourni. Il indique les stop_times que l'opérateur s'efforcera de respecter scrupuleusement (timepoint=1) et que les autres heures d'arrêt sont des estimations (timepoint=0).

arrival_time & departure_time arrival_time et departure_time Les champs devraient spécifier des valeurs temporelles dans la mesure du possible, y compris des temps estimés ou interpolés non contraignants entre les points de temps.

stop_headsign En général, les valeurs des panneaux de tête devraient également correspondre aux panneaux des gares.

Dans les cas ci-dessous, "Southbound" induirait les clients en erreur car il n'est pas utilisé dans les panneaux des stations.

A NYC, pour le 2 en direction du sud :
Pour `stop_times.txt` rangées :	Utilisez `stop_headsign` valeur :
Jusqu'à ce que Manhattan soit atteint	`Manhattan et Brooklyn`
Jusqu'à ce que le centre-ville soit atteint	`Centre-ville et Brooklyn`
Jusqu'à ce que Brooklyn soit atteint	`Brooklyn`
Une fois que Brooklyn est atteint	`Brooklyn (New Lots Av)`

À Boston, pour la Red Line allant vers le sud, pour la branche Braintree :
Pour `stop_times.txt` rangées :	Utiliser `stop_headsign` valeur :
Jusqu'à ce que le centre-ville soit atteint	`En direction de Braintree`
Une fois le centre-ville atteint	`Braintree`
Après Downtown	`En sortant vers Braintree`

shape_dist_traveled shape_dist_traveled ne doit pas être fournie pour les itinéraires comportant une boucle ou un alignement (le véhicule traverse ou parcourt la même portion d'alignement en un seul voyage). Voir la shapes.shape_dist_traveled recommandation.

calendar.txt¶

Nom du champ	Recommandation
Tous les champs	Incluant un `calendar.service_name` peut également améliorer 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	L'inclusion d'un champ `calendar.service_name` L'inclusion d'un champ peut également augmenter la lisibilité humaine de GTFS, bien que cela ne soit pas adopté dans la spécification.

fare_attributes.txt¶

Nom du champ	Recommandation
`agency_id`	Devrait être inclus, même s'il n'y a qu'une seule agence dans le flux. (Voir aussi la recommandation d'inclure `agency_id` sur `agency.txt` et `routes.txt`)
	Si un système tarifaire ne peut être modélisé avec précision, évitez toute confusion supplémentaire et laissez ce champ vide.
	Inclure les tarifs (`fare_attributes.txt` et `fare_rules.txt`) et modélisez-les aussi précisément que possible. Dans les cas limites où les tarifs ne peuvent pas être modélisés avec précision, le tarif devrait ê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 les informations sur les tarifs dans le flux.

fare_rules.txt¶

Nom du champ Recommandation

Tous les champs Si un système de tarification ne peut pas être modélisé avec précision, évitez toute confusion supplémentaire et laissez le 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 limites où les tarifs ne peuvent pas être modélisés avec précision, le tarif devrait ê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 les informations sur les tarifs 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 empruntent le même segment de route ou de voie ferrée), la partie partagée du tracé devrait correspondre exactement. Cela permet de faciliter la cartographie de haute qualité du transport en commun.
	Les tracés devraient suivre la ligne centrale de l'emprise sur laquelle le véhicule circule. Il peut s'agir soit de l'axe de la rue s'il n'y a pas de voies désignées, soit de l'axe du côté de la chaussée qui va dans le sens du déplacement du véhicule. Les alignements ne doivent pas être "en dents de scie" par rapport à un arrêt en bordure de trottoir, une plate-forme ou un lieu d'embarquement.
`shape_dist_traveled`	Il doit être fourni dans les deux cas `shapes.txt` et `stop_times.txt` si un alignement comprend une boucle ou une ligne intérieure (le véhicule traverse ou parcourt la même portion d'alignement en un seul voyage). Si un véhicule retrace ou traverse l'alignement de l'itinéraire à certains endroits au cours d'un trajet, `shape_dist_traveled` il est important de clarifier comment les portions des points en `shapes.txt` l'alignement correspondent aux enregistrements dans `stop_times.txt`.
	Le `shape_dist_traveled` permet à l'agence de spécifier exactement comment les arrêts dans le `stop_times.txt` s'inscrivent dans leur forme respective. Une valeur courante à utiliser pour le champ `shape_dist_traveled` est la distance parcourue par le véhicule depuis le début de la forme (pensez à un relevé d'odomètre). Les alignements de routes (en `shapes.txt`) devraient se situer à moins de 100 mètres des arrêts desservis par un trajet. Simplifiez les alignements de sorte que `shapes.txt` ne contienne pas de points superflus (par exemple, supprimez les points supplémentaires sur les segments de ligne droite ; voir la discussion sur le problème de la simplification des lignes).

frequencies.txt¶

Nom du champ Recommandation

Tous les champs Les temps d'arrêt 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 trajets basés sur la fréquence. Pour des raisons de clarté et de lisibilité, il est recommandé que le premier arrêt d'un déplacement référencé par frequencies.txt devrait commencer à 00:00:00 (première arrival_time valeur 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 GTFS. Ces définitions de transfer_type sont citées de la spécification GTFS ci-dessous, en italique, avec des recommandations pratiques supplémentaires.

Nom du champ	Recommandation
`transfer_type`	0 ou (vide) : Il s'agit d'un point de correspondance recommandé entre les trajets. S'il y a plusieurs possibilités de transfert qui incluent une option supérieure (c'est-à-dire un centre de transit avec des commodités supplémentaires ou une station avec des installations/plates-formes d'embarquement adjacentes ou connectées), indiquez un point de transfert recommandé.
	1 : Il s'agit d'un point de correspondance minuté entre deux itinéraires. Le véhicule qui part doit attendre celui qui arrive, en laissant suffisamment de temps au passager pour passer d'une ligne à l'autre. Ce type de transfert permet de passer outre un intervalle obligatoire pour effectuer des transferts de manière fiable. À titre d'exemple, Google Maps part du principe 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 délai minimum entre l'arrivée et le départ pour assurer une correspondance. Le temps obligatoire pour effectuer le transfert est spécifié par `min_transfer_time`. Spécifiez le temps de transfert minimum s'il y a des obstructions ou d'autres facteurs qui augmentent le temps de trajet entre les arrêts.
	3 : Les transferts ne sont pas possibles entre les lignes à cet endroit. Indiquez cette valeur si les correspondances ne sont pas possibles en raison d'obstacles physiques, ou si elles sont rendues dangereuses ou compliquées par des traversées de route difficiles ou des lacunes dans le réseau piétonnier.
	Si les transferts à l'intérieur du siège (bloc) sont autorisés entre les trajets, le dernier arrêt du trajet d'arrivée doit être le même que le premier arrêt du trajet de départ.

feed_info.txt¶

feed_info.txt devrait être inclus, avec tous les champs ci-dessous.

Nom du champ	Recommandation
`feed_start_date` & `feed_end_date`	Devrait être inclus
`feed_version`	Devrait être inclus
`feed_contact_email` & `feed_contact_url`	Fournissez au moins un

Recommandations pratiques organisées par cas¶

Cette section couvre des cas particuliers ayant des implications sur plusieurs fichiers et champs.

Itinéraires 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 panneaux de signalisation devraient donc être appliquées afin d'indiquer aux usagers la direction dans laquelle le véhicule se déplace.

Pour indiquer le changement de sens de la marche, il faut prévoir des stop_headsigns dans le fichier stop_times.txt. Le panneau stop_headsign décrit la direction des trajets au départ de l'arrêt pour lequel il est défini. L'ajout de panneaux stop_heads à chaque arrêt d'un trajet vous permet de modifier les informations du panneau d'affichage tout au long du trajet.

Ne définissez pas un seul trajet circulaire dans le fichier stop_times.txt pour un itinéraire qui fonctionne entre deux points d'extrémité (comme lorsque le même bus fait des allers-retours). Divisez plutôt le trajet en deux directions distinctes.

Exemples de modélisation de trajets circulaires :

Trajet circulaire avec changement de l'indicateur de direction pour chaque arrêt

trip_id	heure_d'arrivée	heure de départ	stop_id	stop_sequence	panneau d'arrêt
voyage_1	06:10:00	06:10:00	stop_A	1	"B"
voyage_1	06:15:00	06:15:00	stop_B	2	"C"
voyage_1	06:20:00	06:20:00	stop_C	3	"D"
voyage_1	06:25:00	06:25:00	stop_D	4	"E"
voyage_1	06:30:00	06:30:00	stop_E	5	"A"
voyage_1	06:35:00	06:35:00	stop_A	6	""

Voyage circulaire avec deux panneaux indicateurs

trip_id	heure d'arrivée	heure_de_départ	stop_id	stop_sequence	panneau d'arrêt
voyage_1	06:10:00	06:10:00	stop_A	1	"outbound"
voyage_1	06:15:00	06:15:00	stop_B	2	"outbound"
voyage_1	06:20:00	06:20:00	stop_C	3	"outbound"
voyage_1	06:25:00	06:25:00	stop_D	4	"inbound"
voyage_1	06:30:00	06:30:00	stop_E	5	"entrant"
voyage_1	06:35:00	06:35:00	stop_F	6	"entrant"
voyage_1	06:40:00	06:40:00	stop_A	7	""

Nom du champ Recommandation

trips.trip_id Modélisez le trajet circulaire 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 n'effectuent pas la totalité de la boucle. Incluez également ces trajets.

`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 des aiguilles d'une montre et dans le sens inverse des aiguilles d'une montre), indiquez alors direction_id comme 0 ou 1.

trips.block_id Indiquez les trajets en boucle continue avec le même block_id.

Itinéraires Lasso¶

Les itinéraires Lasso combinent les aspects d'un itinéraire en boucle et d'un itinéraire directionnel.

Exemples : Exemples :
Itinéraires de métro (Chicago)
Itinéraires d'autobus de la banlieue au centre-ville (St. Albert ou Edmonton)
CTA Brown Line (Site Web de la 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 déplacement de A à B à B et retour à A. Un aller-retour complet de véhicule peut être exprimé par :
A unique trip_id valeur/enregistrement en trips.txt
Multiple trip_id valeurs/enregistrements en trips.txtLe déplacement continu est indiqué par block_id.

stop_times.stop_headsign

Les arrêts situés le long du tronçon A-B seront franchis dans les deux sens. stop_headsign permet de distinguer plus facilement le sens de la marche. Par conséquent, il est recommandé de fournir stop_headsign est recommandé pour ces déplacements.exemple_table :

Exemples :
"A via B"
"A"

La ligne Purple Line de la Chicago Transit Authority Purple Line
"Southbound via Loop"
"Northbound via Loop"
"Northbound to Linden"

Lignes d'autobus du service de transport en commun d'Edmonton, ici le 39
"Rutherford
"Century Park

trip.trip_headsign L'indicatif de trajet devrait être une description globale du trajet, comme celle affichée dans les horaires. Cela pourrait être "Linden à Linden via Loop" (exemple de Chicago), ou "A à A via B" (exemple générique).

Embranchements¶

Certains itinéraires peuvent comporter des branches. Le tracé et les arrêts sont partagés entre ces branches, mais chacune d'entre elles dessert également des arrêts et des sections de tracé distincts. La relation entre les embranchements peut être indiquée par le(s) nom(s) de l'itinéraire, les panneaux d'affichage et le nom abrégé du trajet en suivant les directives ci-dessous.

Nom du champ	Recommandation
Tous les champs	Pour nommer les lignes secondaires, il est recommandé de suivre les autres documents d'information des passagers. Vous trouverez ci-dessous des descriptions et des exemples de deux cas :
	Si les horaires et la signalisation sur la voie publique indiquent deux itinéraires aux noms distincts (par exemple 1A et 1B), présentez-les comme tels dans le GTFS, en utilisant les champs `route_short_name` et/ou `route_long_name` champs. Exemple : GoDurham Transit les itinéraires 2, 2A et 2B partagent un alignement commun sur la majorité de l'itinéraire, mais ils varient sur plusieurs aspects différents. Le circuit 2 est un service de base, fonctionnant la plupart des heures. Le circuit 2 comprend une déviation sur Main Street les nuits, les dimanches et les jours fériés. Les circuits 2A et 2B fonctionnent en journée du lundi au samedi. Le circuit 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 comme étant le même itinéraire, utilisez les champs suivants `trips.trip_headsign`, `stop_times.stop_headsign`et/ou `trips.trip_short_name` champs. Exemple : GoTriangle itinéraire 300 se rend à différents endroits selon l'heure de la journée. Aux heures de pointe, des tronçons supplémentaires sont ajoutés à l'itinéraire standard pour permettre aux travailleurs d'entrer et de sortir de la ville.

Foire aux questions (FAQ)¶

Pourquoi ces Bonnes Pratiques GTFS sont-elles importantes ?¶

Les objectifs des meilleures pratiques GTFS sont les suivants

Améliorer l'expérience client de l'utilisateur final dans les applications de transport public.
Soutenir une large interopérabilité des données pour faciliter le déploiement et la mise à l'échelle des applications, produits et services par les développeurs de logiciels
Faciliter l'utilisation du GTFS dans diverses catégories d'applications (au-delà de son objectif initial de planification des déplacements).

En l'absence de Bonnes Pratiques GTFS coordonnées, diverses applications GTFS peuvent établir des exigences et des attentes de manière non coordonnée, ce qui conduit à des exigences divergentes et à des ensembles de données spécifiques aux applications et à une moindre interopérabilité. Avant la publication des meilleures pratiques, il y avait une plus grande ambiguïté et des désaccords sur ce qui constitue des données GTFS correctement formées.

Comment ont-elles été développées ? Qui les a élaborées ?¶

Ces meilleures pratiques ont été élaborées par un groupe de travail composé de 17 organisations impliquées dans le programme GTFS, y compris des fournisseurs d'applications et des consommateurs de données, des fournisseurs de services de transport en commun et des consultants très impliqués dans le programme 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 meilleure pratique. La plupart des meilleures pratiques ont été approuvées par un vote unanime. Dans une minorité de cas, les meilleures 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 effectivement entraîné des modifications de la spécification (voir les demandes de retrait fermées dans GitHub). Les modifications des références de la spécification sont soumises à un examen et à des commentaires plus rigoureux que les meilleures pratiques. Cependant, il était encore nécessaire de se mettre d'accord sur un ensemble clair de recommandations de bonnes pratiques.

Le groupe de travail prévoit que certaines meilleures pratiques GTFS feront éventuellement partie de la référence GTFS de base.

Les outils de validation du GTFS vérifient-ils la conformité à ces meilleures pratiques ?¶

Aucun outil de validation ne vérifie actuellement la conformité avec toutes les bonnes pratiques. Divers outils de validation vérifient la conformité avec certaines de ces meilleures pratiques. Pour obtenir une liste des outils de validation GTFS, consultez les GTFS Validators. Si vous écrivez un outil de validation GTFS qui fait référence à ces meilleures pratiques, veuillez envoyer un courriel à specifications@mobilitydata.org.

Je représente une agence de transport en commun. Quelles mesures puis-je prendre pour que nos fournisseurs de services logiciels et nos vendeurs suivent ces Meilleures Pratiques ?¶

Renvoyez votre fournisseur ou votre prestataire de services logiciels à ces meilleures pratiques. Nous recommandons de faire référence à l'URL des meilleures pratiques GTFS, ainsi qu'à la référence des spécifications de base lors de l'achat de logiciels GTFS.

Que dois-je faire si je constate qu'un flux de données GTFS n'est pas conforme à ces Meilleures Pratiques ?¶

Identifiez le contact pour le flux, en utilisant les champs proposés feed_contact_email ou feed_contact_url dans feed_info.txt s'ils existent, ou en recherchant les informations de contact sur le site Web de l'agence de transport ou du producteur de flux. Lorsque vous communiquez le problème au producteur d'aliments pour animaux, établissez un lien vers la meilleure pratique GTFS en question. (Voir "Lien vers ce document").

J'aimerais proposer une modification/un ajout aux Meilleures Pratiques. Comment puis-je le faire ?¶

Envoyez un courriel à specifications@mobilitydata.org ou ouvrez une question ou une demande de retrait dans le GitHub GTFS Best Practices repo.

Comment puis-je m'impliquer ?¶

Envoyez un courriel à specifications@mobilitydata.org.

A propos de ce document¶

Objectifs¶

Les objectifs du maintien des meilleures pratiques GTFS sont les suivants :

Soutenir une plus grande interopérabilité des données de transport en commun
Améliorer l'expérience de l'utilisateur final dans les applications de transport public.
Faciliter le déploiement et la mise à l'échelle des applications, produits et services par les développeurs de logiciels.
Faciliter l'utilisation de GTFS dans diverses catégories d'applications (au-delà de son objectif initial de planification des trajets).

Comment proposer ou modifier les meilleures pratiques GTFS publiées ?¶

Les applications et pratiques GTFS évoluent, et ce document peut donc devoir être modifié de temps en temps. Pour proposer un amendement à ce document, ouvrez une demande de retrait dans le dépôt GitHub GTFS Best Practices et préconisez le changement. Vous pouvez également envoyer vos commentaires par courriel à specifications@mobilitydata.org.

Liens vers ce document¶

Veuillez établir un lien ici afin de fournir aux producteurs de flux des conseils pour la formation 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 GTFS formule des exigences ou des recommandations pour les pratiques relatives aux données GTFS qui ne sont pas décrites ici, il est recommandé de publier un document avec ces exigences ou recommandations pour compléter ces meilleures pratiques communes.

Groupe de travail sur les meilleures pratiques GTFS¶

Le groupe de travail sur les meilleures pratiques GTFS a été convoqué par le Rocky Mountain Institute en 2016-17, composé de fournisseurs de transport public, de développeurs d'applications GTFS, de consultants et d'organisations universitaires, afin de définir des pratiques et des attentes communes pour les données GTFS. Les membres de ce groupe de travail comprenaient :

Aujourd'hui, ce document est maintenu par MobilityData.