Référence du GTFS Schedule¶

Révisé le 8 décembre 2022. Voir l'historique des révisions pour plus de détails.

Ce document définit le format et la structure des fichiers qui composent un ensemble de données GTFS.

Table des matières¶

Conventions des documents
Fichiers de données
Exigences relatives aux fichiers
Définitions des champs

Conventions des documents¶

Les mots clés "DOIT", "NE DOIT PAS", "OBLIGATOIRE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDÉ", "NON RECOMMANDÉE" et "OPTIONNELLE" dans ce document doivent être interprétés comme décrit dans la RFC 2119.

Définitions des termes¶

Cette section définit les termes utilisés dans ce document.

Ensemble de données - Ensemble complet de fichiers définis par la présente référence de spécification. La modification de l'ensemble de données crée une nouvelle version de l'ensemble de données. Les ensembles de données devraient être publiés à une URL publique et permanente, incluant le nom du fichier zip. (par exemple, https://www.agency.org/gtfs/gtfs/zip).
Enregistrement - Structure de données de base composée d'un certain nombre de valeurs de champs différents décrivant une seule entité (par exemple, une agence de transport, un arrêt, un itinéraire, etc.) Représenté, dans un tableau, par une ligne.
Champ - Propriété d'un objet ou d'une entité. Représenté, dans un tableau, comme une colonne.
Valeur de champ - Une entrée individuelle dans un champ. Représentée, dans un tableau, par une seule cellule.
Jour de service - Un jour de service est une période de temps utilisée pour indiquer l'ordonnancement des itinéraires. La définition exacte d'un jour de service varie d'une agence à l'autre, mais les jours de service ne correspondent souvent pas aux jours civils. Un jour de service peut dépasser 24:00:00 si le service commence un jour et se termine le jour suivant. Par exemple, un service qui fonctionne de 08:00:00 le vendredi à 02:00:00 le samedi, pourrait être désigné comme fonctionnant de 08:00:00 à 26:00:00 sur un seul jour de service.
Champ de synthèse vocale - Le champ devrait contenir les mêmes informations que son champ parent (sur lequel il se rabat s'il est vide). Il est destiné à être lu en synthèse vocale, par conséquent, les abréviations devraient être soit supprimées ("St" devrait être lu comme "Street" ou "Saint" ; "Elizabeth I" devrait être "Elizabeth the first") soit conservées pour être lues telles quelles ("JFK Airport" est dit abrégé).
Étape - Voyage au cours duquel un voyageur monte et descend entre deux endroits successifs au cours d'un voyage.
Voyage - Voyage global du point d'origine à la destination, y compris toutes les étapes et les transferts intermédiaires.
Sous-voyage - Deux ou plusieurs étapes qui constituent un sous-ensemble d'un voyage.
Produit tarifaire - Produits tarifaires achetables qui peuvent être utilisés pour payer ou valider un voyage.

Présence¶

Conditions de présence applicables aux champs et aux fichiers :

Obligatoire - Le champ ou le fichier doit être inclus dans l'ensemble de données et contenir une valeur valide pour chaque enregistrement.
Optionnelle - Le champ ou le fichier peut être omis de l'ensemble de données.
Conditionnellement obligatoire - Le champ ou le dossier doit être inclus dans les conditions décrites dans la description du champ ou du dossier.
Conditionnellement interdit - Le champ ou le fichier ne doit pas être inclus dans les conditions décrites dans la description du champ ou du fichier.

Types de champs¶

Couleur - Une couleur codée sous la forme d'un nombre hexadécimal à six chiffres. Reportez-vous à https://htmlcolorcodes.com pour générer une valeur valide (le "#" de tête ne doit pas être inclus).
Exemple : FFFFFF pour le blanc, 000000 pour le noir ou 0039A6 pour les lignes A, C, E de NYMTA.
Code devise - Un code devise alphabétique ISO 4217. Pour obtenir la liste des devises actuelles, consultez le site https://en.wikipedia.org/wiki/ISO_4217#Active_codes.
Exemple : CAD pour les dollars canadiens, EUR pour les euros ou JPY pour les yens japonais.
Montant en devise - Une valeur décimale indiquant un montant en devise. Le nombre de décimales est spécifié par la norme ISO 4217 pour le code de devise correspondant. Tous les calculs financiers devraient être traités sous forme de décimales, de devises ou d'un autre type équivalent adapté aux calculs financiers, selon le language programmation utilisé pour consommer les données. Il est déconseillé de traiter les montants en devise en tant que flottant en raison des gains ou des pertes d'argent pendant les calculs.
Date - Jour de service au format AAAAMMJJ. Étant donné que l'heure d'un jour de service peut être supérieure à 24:00:00, un jour de service peut contenir des informations pour le ou les jours suivants.
Exemple : 20180913 pour le 13 septembre 2018.
Email - Une adresse électronique.
Exemple : example@example.com
Enum - Une option parmi un ensemble de constantes prédéfinies définies dans la colonne "Description".
Exemple : Le champ route_type contient un 0 pour le tram, un 1 pour le métro...
ID - La valeur d'un champ ID est un identifiant interne, qui n'est pas destiné à être montré aux usagers, et est une séquence de caractères UTF-8. Il est recommandé de n'utiliser que des caractères ASCII imprimables. Un ID est appelé "ID unique" lorsqu'il doit être unique dans un fichier. Les ID définis dans un fichier .txt sont souvent référencés dans un autre fichier .txt. Les ID qui font référence à un ID dans une autre table sont appelés "ID étranger".
Exemple : Le champ stop_id dans stops.txt est un "ID unique". Le champ parent_station dans stops.txt est un "identifiant étranger référençant stops.stop_id".
Code de langue - Un code de langue IETF BCP 47. Pour une introduction à l'IETF BCP 47, reportez-vous à https://www.rfc-editor.org/rfc/bcp/bcp47.txt et https://www.w3.org/International/articles/language-tags/.
Exemple : en pour l'anglais, en-US pour l'anglais américain ou de pour l'allemand.
Latitude - Latitude WGS84 en degrés décimaux. La valeur doit être supérieure ou égale à -90,0 et inférieure ou égale à 90,0.
Exemple : 41,890169 pour le Colisée de Rome.
Longitude - Longitude WGS84 en degrés décimaux. La valeur doit être supérieure ou égale à -180,0 et inférieure ou égale à 180,0.
Exemple : 12,492269 pour le Colisée de Rome.
Float - Un nombre à virgule flottante.
Integer - Un nombre entier.
Phone number - Un numéro de téléphone.
Heure - Heure au format HH:MM:SS (H:MM:SS est également accepté). L'heure est mesurée à partir de "midi moins 12h" du jour de service (effectivement minuit, sauf pour les jours de changement d'heure d'été). Pour les heures se produisant après minuit, saisissez l'heure sous la forme d'une valeur supérieure à 24:00:00 en heure locale HH:MM:SS pour le jour où l'horaire de voyage commence.
Exemple : 14:30:00 pour 2:30PM ou 25:35:00 pour 1:35AM le jour suivant.
Texte - Une chaîne de caractères UTF-8, destinée à être affichée et qui doit donc être lisible par l'homme.
Fuseau horaire - Fuseau horaire TZ du site https://www.iana.org/time-zones. Les noms de fuseaux horaires ne contiennent jamais le caractère espace mais peuvent contenir un trait de soulignement. Reportez-vous à https://en.wikipedia.org/wiki/List_of_tz_zones pour obtenir la liste des valeurs valides.
Exemple : Asia/Tokyo, America/Los_Angeles ou Africa/Cairo.
URL - Une URL entièrement qualifiée qui comprend http:// ou https://, et tout caractère spécial dans l'URL doit être correctement échappé. Consultez le site suivant https://www.w3.org/Addressing/URL/4_URI_Recommentations.html pour savoir comment créer des valeurs d'URL entièrement qualifiées.

Signes des champs¶

Signes applicables aux types de champs Float ou Integer :

Non-négatif - Supérieur ou égal à 0.
Non-zéro - Non égal à 0.
Positif - Supérieur à 0.

Exemple : Flottant non négatif** - Un nombre à virgule flottante supérieur ou égal à 0.

Attributs de l'ensemble de données¶

La clé primaire d'un ensemble de données est le champ ou la combinaison de champs qui identifie de manière unique une ligne. La clé primaire (*) est utilisée lorsque tous les champs fournis pour un fichier sont utilisés pour identifier de manière unique une ligne. La clé primaire (none) signifie que le fichier ne permet qu'une seule ligne.

Exemple : les champs trip_id et stop_sequence constituent la clé primaire de stop_times.txt.

Fichiers de données¶

Cette spécification définit les fichiers suivants :

Nom du fichier	Présence	Description
agency.txt	Obligatoire	Agences de transport en commun dont le service est représenté dans cet ensemble de données.
stops.txt	Obligatoire	Arrêts où les véhicules prennent ou déposent les usagers. Définit également les stations et les entrées de station.
routes.txt	Obligatoire	Itinéraires de transport en commun. Un itinéraire est un groupe de trajets qui sont présentés aux usagers comme un service unique.
trips.txt	Obligatoire	Trajets pour chaque ligne. Un trajet est une séquence de deux arrêts ou plus qui se produisent pendant une période de temps spécifique.
stop_times.txt	Obligatoire	Les heures d'arrivée et de départ d'un véhicule aux arrêts pour chaque trajet.
calendar.txt	Conditionnellement obligatoire	Les dates de service spécifiées à l'aide d'un horaire hebdomadaire avec des dates de début et de fin. Conditionnellement obligatoire : - Obligatoire sauf si toutes les dates de service sont définies dans calendar_dates.txt. - Optionnelle autrement.
calendar_dates.txt	Conditionnellement obligatoire	Les exceptions pour les services définis dans le calendar.txt. Conditionnellement obligatoire : - Obligatoire si calendar.txt est omise. Dans ce cas calendar_dates.txt doit contenir toutes les dates de service. - Optionnelle autrement.
fare_attributes.txt	Optionnelle	Les informations tarifaires pour les itinéraires d'une agence de transport en commun.
fare_rules.txt	Optionnelle	Règles d'application des tarifs pour les itinéraires. Conditionnellement obligatoire : - Obligatoire si fare_attributes.txt est défini. - Interdit autrement.
fare_media.txt	Optionnelle	Décrire les supports tarifaires qui peuvent être utilisés pour utiliser les produits tarifaires. Le fichier fare_media.txt décrit des concepts qui ne sont pas représentés dans les fichiers fare_attributes.txt et fare_rules.txt. En tant que tel, l'utilisation du fichier fare_media.txt est entièrement distincte des fichiers fare_attributes.txt et fare_rules.txt
fare_products.txt	Optionnelle	Décrire les différents types de billets ou de tarifs qui peuvent être achetés par les usagers. Fichier fare_products.txt décrit les produits tarifaires qui ne sont pas représentés dans fare_attributes.txt et fare_rules.txt. En tant que telle, l'utilisation de fare_products.txt est entièrement séparée des fichiers fare_attributes.txt et fare_rules.txt.
fare_leg_rules.txt	Optionnelle	Règles tarifaires pour les différentes étapes du voyage. Fichier fare_leg_rules.txt fournit une méthode plus détaillée pour modéliser les structures tarifaires. Ainsi, l'utilisation de fare_leg_rules.txt est entièrement séparé des fichiers fare_attributes.txt et fare_rules.txt.
fare_transfer_rules.txt	Optionnelle	Règles tarifaires pour les transferts entre les étapes du voyage. Avec fare_leg_rules.txt fichier fare_transfer_rules.txt fournit une méthode plus détaillée pour la modélisation des structures tarifaires. En tant que telle, l'utilisation de fare_transfer_rules.txt est entièrement séparé des fichiers fare_attributes.txt et fare_rules.txt.
areas.txt	Optionnelle	Regroupement d'emplacements par zone.
stop_areas.txt	Optionnelle	Règles d'affectation des arrêts aux zones.
shapes.txt	Optionnelle	Règles pour cartographier les trajets des véhicules, parfois appelées alignements d'itinéraires.
frequencies.txt	Optionnelle	Trajet (temps entre les trajets) pour un service basé sur le trajet ou une représentation comprimée d'un service à horaire fixe.
transfers.txt	Optionnelle	Règles pour établir des correspondances aux points de transfert entre les itinéraires.
pathways.txt	Optionnelle	Les chemins reliant les emplacements dans les stations.
levels.txt	Conditionnellement obligatoire	Niveaux dans les stations. Conditionnellement obligatoire : - Obligatoire lors de la description de cheminements avec ascenseurs (`pathway_mode=5`). - Optionnelle otherwise.
translations.txt	Optionnelle	Traductions des valeurs des ensembles de données destinés aux clients.
feed_info.txt	Optionnelle	Métadonnées de l'ensemble de données, y compris les informations sur l'éditeur, la version et l'expiration.
attributions.txt	Optionnelle	Attributions des ensembles de données.

Exigences relatives aux fichiers¶

Les exigences suivantes s'appliquent au format et au contenu des fichiers de l'ensemble de données :

Tous les fichiers doivent être enregistrés sous forme de texte délimité par des virgules.
La première ligne de chaque fichier ne contient pas de noms de champs. Chaque sous-section de la section Définitions des champs correspond à l'un des fichiers d'un ensemble de données GTFS et énumère les noms de champs qui peuvent être utilisés dans ce fichier.
Tous les noms de fichiers et de champs sont sensibles à la casse.
Les valeurs des champs ne doivent pas contenir de tabulation, de retour chariot ou de nouvelle ligne.
Les valeurs de champ qui contiennent des guillemets ou des virgules doivent être placées entre guillemets. En outre, chaque guillemet dans la valeur du champ doit être précédé d'un guillemet. Cela correspond à la manière dont Microsoft Excel produit des fichiers CSV (comma-delimited). Pour plus d'informations sur le format de fichier CSV, voir https://tools.ietf.org/html/rfc4180.

L'exemple suivant montre comment une valeur de champ apparaît dans un fichier délimité par des virgules :

Valeur originale du champ : Contient des "guillemets", des virgules et du texte.
Valeur du champ dans le fichier CSV : "Contient des ""guillemets"", des virgules et du texte".
Les valeurs des champs ne doivent pas contenir de balises HTML, de commentaires ou de séquences d'échappement.
Les espaces supplémentaires entre les champs ou les noms de champs devraient être supprimés. De nombreux analyseurs considèrent que les espaces font partie de la valeur, ce qui peut entraîner des erreurs.
Chaque ligne doit se terminer par un caractère de saut de ligne CRLF ou LF.
Les fichiers doivent être codés en UTF-8 pour prendre en charge tous les caractères Unicode. Les fichiers qui incluent le caractère Unicode byte-order mark (BOM) sont acceptables. Voir https://unicode.org/faq/utf_bom.html#BOM pour plus d'informations sur le caractère BOM et UTF-8.
Tous les fichiers de l'ensemble de données doivent être compressés ensemble.

Définitions des champs¶

agency.txt¶

Fichier : Obligatoire

Clé primaire (agency_id)

Nom du champ	Type	Présence	Description
`agency_id`	ID unique	Conditionnellement obligatoire	Identifie une marque de transport en commun qui est souvent synonyme d'une agence de transport en commun. Notez que dans certains cas, par exemple lorsqu'une seule agence exploite plusieurs services distincts, les agences et les marques sont distinctes. Ce document utilise le terme "agence" à la place de "marque". Un ensemble de données peut contenir des données provenant de plusieurs agences. Conditionnellement obligatoire : - Obligatoire lorsque l'ensemble de données contient des données pour plusieurs agences de transport. - Optionnelle otherwise.
`agency_name`	Texte	Obligatoire	Nom complet de l'agence de transport.
`agency_url`	URL	Obligatoire	URL de l'agence de transport.
`agency_timezone`	Fuseau horaire	Obligatoire	Fuseau horaire où se trouve l'agence de transport. Si plusieurs agences sont spécifiées dans l'ensemble de données, chacune d'entre elles doit avoir le même nom. `agency_timezone`.
`agency_lang`	Code de langue	Optionnelle	language principale utilisée par cette agence de transport. Devrait être fourni pour aider les consommateurs de GTFS à choisir les règles de capitalisation et autres paramètres language pour l'ensemble de données.
`agency_phone`	Numéro de téléphone	Optionnelle	Un numéro de téléphone vocal pour l'agence spécifiée. Ce champ est une chaîne de caractères qui présente le numéro de téléphone comme typique de la zone de service de l'agence. Il peut contenir des signes de ponctuation pour regrouper les chiffres du numéro. Le texte à composer (par exemple, le "503-238-RIDE" de TriMet) est autorisé, mais le champ ne doit pas contenir d'autre texte descriptif.
`agency_fare_url`	URL	Optionnelle	URL d'une page Web qui permet à un usager d'acheter en ligne des billets ou d'autres instruments tarifaires pour cette agence.
`agency_email`	Courriel	Optionnelle	Adresse électronique surveillée activement par le service clientèle de l'agence. Cette adresse électronique devrait être un point de contact direct où les usagers du transport en commun peuvent joindre un représentant du service clientèle de l'agence.

stops.txt¶

Fichier : Obligatoire

Clé primaire (stop_id)

Nom du champ	Type	Présence	Description
`stop_id`	ID unique	Obligatoire	Identifie un emplacement : arrêt/plateforme, station, entrée/sortie, nœud générique ou zone d'embarquement (cf. `location_type`). Plusieurs itinéraires peuvent utiliser le même identifiant. `stop_id`.
`stop_code`	Texte	Optionnelle	Texte court ou numéro qui identifie l'emplacement pour les usagers. Ces codes sont souvent utilisés dans les systèmes d'information sur les transports en commun par téléphone ou imprimés sur les panneaux de signalisation pour permettre aux usagers d'obtenir plus facilement des informations sur un lieu particulier. Le site `stop_code` peut être le même que `stop_id` s'il s'agit d'un lieu public. Ce champ devrait être laissé vide pour les lieux sans code présenté aux usagers.
`stop_name`	Texte	Obligatoire sous condition	Nom de l'emplacement. Le site `stop_name` devrait correspondre au nom de l'emplacement utilisé par l'agence à l'intention des usagers, tel qu'il est imprimé sur les horaires, publié en ligne ou représenté sur la signalisation. Pour les traductions dans d'autres langues, utilisez `translations.txt`. Lorsque le lieu est une zone d'embarquement (`location_type=4`), le `stop_name` devrait contenir le nom de la zone d'embarquement tel qu'il est affiché par l'agence. Il peut s'agir d'une seule lettre (comme dans certaines gares interurbaines européennes), ou d'un texte tel que "Zone d'embarquement pour les fauteuils roulants" (métro de New York) ou "Tête des trains courts" (RER de Paris). Conditionnellement obligatoire : - Obligatoire pour les lieux qui sont des arrêts (`location_type=0`), des stations (`location_type=1`) ou des entrées/sorties (`location_type=2`). - Optionnelle pour les emplacements qui sont des nœuds génériques (`location_type=3`) ou des zones d'embarquement (`location_type=4`).
`tts_stop_name`	Texte	Optionnelle	Version lisible de l'option `stop_name`. Voir "Champ de synthèse vocale" dans le document Définitions des termes pour en savoir plus.
`stop_desc`	Texte	Optionnelle	Description de l'emplacement qui fournit des informations utiles et de qualité. Devrait ne pas être un doublon de `stop_name`.
`stop_lat`	Latitude	Obligatoire sous condition	Latitude de l'emplacement. Pour les arrêts/plateformes (`location_type=0`) et la zone d'embarquement (`location_type=4`), les coordonnées doivent être celles du poteau du bus - s'il existe - et sinon de l'endroit où les voyageurs montent dans le véhicule (sur le trottoir ou le quai, et non sur la chaussée ou la voie où le véhicule s'arrête). Conditionnellement obligatoire : - Obligatoire pour les lieux qui sont des arrêts (`location_type=0`), des stations (`location_type=1`) ou des entrées/sorties (`location_type=2`). - Optionnelle pour les emplacements qui sont des nœuds génériques (`location_type=3`) ou des zones d'embarquement (`location_type=4`).
`stop_lon`	Longitude	Obligatoire sous condition	Longitude de l'emplacement. Pour les arrêts/plates-formes (`location_type=0`) et la zone d'embarquement (`location_type=4`), les coordonnées doivent être celles du poteau de bus - s'il existe - et sinon de l'endroit où les voyageurs montent dans le véhicule (sur le trottoir ou le quai, et non sur la chaussée ou la voie où le véhicule s'arrête). Conditionnellement obligatoire : - Obligatoire pour les lieux qui sont des arrêts (`location_type=0`), des stations (`location_type=1`) ou entrées/sorties (`location_type=2`). - Optionnelle pour les lieux qui sont des nœuds génériques (`location_type=3`) ou des zones d'embarquement (`location_type=4`).
`zone_id`	ID	Obligatoire sous condition	Identifie la zone tarifaire d'un arrêt. Si cet enregistrement représente une station ou une entrée de station, l'élément `zone_id` est ignorée. Conditionnellement obligatoire : - Obligatoire si l'information tarifaire est fournie par fare_rules.txt - Optionnelle autrement.
`stop_url`	URL	Optionnelle	URL d'une page Web sur l'emplacement. Elle devrait être différente de l'URL `agency.agency_url` et de la `routes.route_url` valeurs du champ.
`location_type`	Enum	Optionnelle	Type d'emplacement. Les options valides sont : `0` (ou blanc) - Arrêt (ou Plate-forme). Emplacement où les passagers embarquent ou débarquent d'un véhicule de transport en commun. Est appelé quai lorsqu'il est défini dans une `parent_station`. `1` - Station. Une structure physique ou une zone qui contient un ou plusieurs quais. `2` - Entrée/sortie. Un endroit où les passagers peuvent entrer ou sortir d'une station depuis la rue. Si une entrée/sortie appartient à plusieurs stations, elle peut être reliée par des chemins aux deux, mais le fournisseur de données ne doit pas choisir l'une d'entre elles comme parent. `3` - Nœud générique. Un emplacement à l'intérieur d'une station, ne correspondant à aucune autre station. `location_type`Il peut être utilisé pour relier entre eux les chemins définis dans le pathways.txt. `4` - Zone d'embarquement. Un emplacement spécifique sur un quai, où les passagers peuvent monter et/ou descendre des véhicules.
`parent_station`	Référencement d'identifiants étrangers `stops.stop_id`	Obligatoire sous condition	Définit la hiérarchie entre les différents emplacements définis dans `stops.txt`. Il contient l'ID de l'emplacement parent, comme suit : - Arrêt/plate-forme (`location_type=0`) : le `parent_station` contient l'ID d'une station. - Station (`location_type=1`) : ce champ ne doit pas être vide. - Entrée/sortie (`location_type=2`) ou nœud générique (`location_type=3`) : le `parent_station` le champ contient l'ID d'une station (`location_type=1`) - Zone d'embarquement (`location_type=4`) : le champ `parent_station` le champ contient l'ID d'un quai. Conditionnellement obligatoire : - Obligatoire pour les emplacements qui sont des entrées (`location_type=2`), des nœuds génériques (`location_type=3`) ou des zones d'embarquement (`location_type=4`). - Optionnelle pour les arrêts/plateformes (`location_type=0`). - Interdit pour les stations (`location_type=1`).
`stop_timezone`	Fuseau horaire	Optionnelle	Fuseau horaire de l'emplacement. Si l'emplacement a une station mère, il hérite du fuseau horaire de la station mère au lieu d'appliquer le sien. Les stations et les arrêts sans parent avec des `stop_timezone` héritent du fuseau horaire spécifié par `agency.agency_timezone`. Si `stop_timezone` Si des valeurs sont fournies, les heures dans stop_times.txt devraient être saisies comme le temps depuis minuit dans le fuseau horaire spécifié par `agency.agency_timezone`. Cela garantit que les valeurs horaires d'un trajet augmentent toujours au cours du trajet, quels que soient les fuseaux horaires traversés par le trajet.
`wheelchair_boarding`	Enum	Optionnelle	Indique si l'embarquement en fauteuil roulant est possible à partir de ce lieu. Les options valides sont : Pour les arrêts sans parents : `0` ou vide - Aucune information sur l'accessibilité de l'arrêt. `1` - Certains véhicules de cet arrêt peuvent être embarqués par un usager en fauteuil roulant. `2` - L'embarquement en fauteuil roulant n'est pas possible à cet arrêt. Pour les arrêts avec enfant : `0` ou vide - L'arrêt hérite du comportement de la `wheelchair_boarding` comportement de la station mère, si cela est spécifié dans la station mère. `1` - Il existe un chemin accessible depuis l'extérieur de la station vers l'arrêt/plateforme spécifique. `2` - Il n'existe pas de chemin accessible depuis l'extérieur de la station jusqu'à l'arrêt/plate-forme spécifique. Pour les entrées/sorties de station : `0` ou vide - L'entrée de la station hérite du comportement `wheelchair_boarding` comportement de la station mère, s'il est spécifié pour la station mère. `1` - L'entrée de la station est accessible aux fauteuils roulants. `2` - Pas de chemin accessible de l'entrée de la station aux arrêts/plates-formes.
`level_id`	Référencement d'identifiants étrangers `levels.level_id`	Optionnelle	Niveau de l'emplacement. Le même niveau peut être utilisé par plusieurs stations non liées.
`platform_code`	Texte	Optionnelle	Identifiant de quai pour un arrêt de quai (un arrêt appartenant à une station). Il devrait s'agir uniquement de l'identifiant du quai (par exemple, "G" ou "3"). Des mots comme "platform" ou "track" (ou l'équivalent language flux) ne devraient pas être inclus. Cela permet aux consommateurs de flux d'internationaliser et de localiser plus facilement l'identifiant de la plateforme dans d'autres langues.

routes.txt¶

Fichier : Obligatoire

Clé primaire (route_id)

Nom du champ	Type	Présence	Description
`route_id`	ID unique	Obligatoire	Identifie un itinéraire.
`agency_id`	Référencement d'identifiants étrangers `agency.agency_id`	Obligatoire sous condition	Agence pour l'itinéraire spécifié. Conditionnellement obligatoire : - Obligatoire si plusieurs agences sont définies dans agency.txt. - Optionnelle autrement.
`route_short_name`	Texte	Obligatoire sous condition	Nom court d'une route. Il s'agit souvent d'un identifiant court et abstrait (par exemple, "32", "100X", "Green") que les usagers utilisent pour identifier un itinéraire. Les deux `route_short_name` et `route_long_name` peut être défini. Conditionnellement obligatoire : - Obligatoire si `routes.route_long_name` est vide. - Optionnelle autrement.
`route_long_name`	Texte	Obligatoire sous condition	Nom complet d'un itinéraire. 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. Les deux `route_short_name` et `route_long_name` peut être défini. Conditionnellement obligatoire : - Obligatoire si `routes.route_short_name` est vide. - Optionnelle autrement.
`route_desc`	Texte	Optionnelle	Description d'un itinéraire qui fournit des informations utiles et de qualité. Ne devrait pas être un doublon de `route_short_name` ou `route_long_name`. Exemple : Les trains "A" circulent en permanence entre Inwood-207 St, Manhattan et Far Rockaway-Mott Avenue, Queens. De plus, de 6 heures à minuit environ, des trains "A" supplémentaires circulent entre Inwood-207 St et Lefferts Boulevard (les trains alternent généralement entre Lefferts Blvd et Far Rockaway).
`route_type`	Enum	Obligatoire	Indique le type de transport utilisé sur un itinéraire. Les options valides sont : `0` - Tram, Tramway, Train léger sur rail. Tout système de rail léger ou de rue dans une zone métropolitaine. `1` - Métro, Subway. Tout système ferroviaire souterrain dans une zone métropolitaine. `2` - Rail. Utilisé pour les déplacements interurbains ou à longue distance. `3` - Bus. Utilisé pour les lignes d'autobus à courte et longue distance. `4` - Ferry. Utilisé pour les services de bateaux à courte et longue distance. `5` - Tramway à câble. Utilisé pour les voitures ferroviaires au niveau de la rue où le câble passe sous le véhicule (par exemple, le téléphérique de San Francisco). `6` - Ascenseur aérien, téléphérique suspendu (par exemple, télécabine, tramway aérien). Transport par câble où les cabines, les voitures, les gondoles ou les chaises ouvertes sont suspendues au moyen d'un ou de plusieurs câbles. `7` - Funiculaire. Tout système ferroviaire conçu pour des pentes raides. `11` - Trolleybus. Bus électriques qui tirent leur énergie de fils aériens à l'aide de poteaux. `12` - Monorail. Chemin de fer dans lequel la voie est constituée d'un seul rail ou d'une poutre.
`route_url`	URL	Optionnelle	URL d'une page web sur l'itinéraire en question. Devrait être différent de la `agency.agency_url` valeur.
`route_color`	Couleur	Optionnelle	Désignation de la couleur de l'itinéraire qui correspond au matériel destiné au public. La valeur par défaut est le blanc (`FFFFFF`) lorsqu'elle est omise ou laissée vide. La différence de couleur entre `route_color` et `route_text_color` devrait fournir un contraste suffisant sur un écran noir et blanc.
`route_text_color`	Couleur	Optionnelle	Couleur lisible à utiliser pour le texte dessiné sur un arrière-plan composé de `route_color`. La valeur par défaut est le noir (`000000`) lorsqu'elle est omise ou laissée vide. La différence de couleur entre `route_color` et `route_text_color` devrait fournir un contraste suffisant sur un écran noir et blanc.
`route_sort_order`	Nombre entier non négatif	Optionnelle	Ordonne les itinéraires de manière à ce qu'ils soient idéalement présentés aux clients. Les itinéraires avec les plus petites `route_sort_order` valeurs devraient être affichées en premier.
`continuous_pickup`	Enum	Optionnelle	Indique que l'usager peut monter à bord du véhicule de transport en commun à n'importe quel point de la trajectoire du véhicule décrite par `shapes.txt`sur chaque trajet de l'itinéraire. Les options valides sont : `0` - Ramassage avec arrêt continu. `1` ou vide - Pas de ramassage avec arrêt continu. `2` - Appelez l'agence pour organiser un ramassage avec arrêt continu. `3` - Veuillez vous mettre d'accord avec le chauffeur pour organiser un ramassage avec arrêt continu. Valeurs pour `routes.continuous_pickup` peuvent être remplacées par des valeurs définies dans `stop_times.continuous_pickup` pour les spécifiques `stop_time`s le long de l'itinéraire.
`continuous_drop_off`	Enum	Optionnelle	Indique que l'usager peut descendre du véhicule de transport en commun à n'importe quel point de son trajet, tel que décrit par l'article 3.1.1. `shapes.txt`, à chaque trajet de l'itinéraire. Les options valides sont : `0` - Arrêt continu de la descente. `1` ou vide - Pas d'arrêt continu. `2` - Appelez l'agence pour organiser un arrêt continu. `3` - Coordonner avec le conducteur pour organiser un arrêt continu. Les valeurs pour `routes.continuous_drop_off` peut être remplacée par la définition de valeurs dans `stop_times.continuous_drop_off` pour spécifique `stop_time`s le long de l'itinéraire.
`network_id`	ID	Optionnelle	Identifie un groupe d'itinéraires. Plusieurs lignes en routes.txt peuvent avoir le même `network_id`.

trips.txt¶

Fichier : Obligatoire

Clé primairetrip_id)

Nom du champ	Type	Présence	Description
`route_id`	Référencement d'identifiants étrangers `routes.route_id`	Obligatoire	Identifie un itinéraire.
`service_id`	Référencement d'un identifiant étranger `calendar.service_id` ou `calendar_dates.service_id`	Obligatoire	Identifie un ensemble de dates où le service est disponible pour un ou plusieurs itinéraires.
`trip_id`	Unique ID	Obligatoire	Identifie un voyage.
`trip_headsign`	Texte	Optionnelle	Texte qui apparaît sur la signalisation et qui identifie la destination du trajet aux usagers. Peut être utilisé pour distinguer différents modèles de service sur un même itinéraire. Si le panneau d'indication change au cours d'un trajet, les valeurs de `trip_headsign` peut être remplacée par la définition de valeurs dans `stop_times.stop_headsign` pour spécifiques `stop_time` le long du trajet.
`trip_short_name`	Texte	Optionnelle	Texte à destination du public utilisé pour identifier le trajet aux usagers, par exemple, pour identifier les numéros de train pour les trajets en train de banlieue. Si les voyageurs ne se fient pas souvent aux noms des trajets, `trip_short_name` devrait être vide. A `trip_short_name` si elle est fournie, devrait identifier de manière unique un trajet au cours d'une journée de service ; elle ne devrait pas être utilisée pour les noms de destination ou les désignations limitées/express.
`direction_id`	Enum	Optionnelle	Indique le sens de déplacement d'un trajet. Ce champ ne devrait pas être utilisé pour le routage ; il permet de séparer les trajets par direction lors de la publication des tableaux horaires. Les options valides sont les suivantes : `0` - Voyage dans une direction (par exemple, voyage sortant). `1` - Voyage dans la direction opposée (par exemple, voyage entrant). Exemple : Le site `trip_headsign` et `direction_id` Les champs peuvent être utilisés ensemble pour attribuer un nom aux déplacements dans chaque direction pour un ensemble de déplacements. A trips.txt peut contenir ces enregistrements pour les utiliser dans des tables de temps : `trip_id,...,trip_headsign,direction_id` `1234,...,Airport,0` `1505,...,Downtown,1`
`block_id`	ID	Optionnelle	Identifie le bloc auquel le voyage appartient. Un bloc est constitué d'un seul déplacement ou de plusieurs déplacements séquentiels effectués avec le même véhicule, définis par des jours de service partagés et par des jours de service différents. `block_id`. A `block_id` peut avoir des trajets avec des jours de service différents, constituant ainsi des blocs distincts. Voir l'exemple exemple ci-dessous.
`shape_id`	Référencement d'identifiants étrangers `shapes.shape_id`	Obligatoire sous condition	Identifie une forme géospatiale décrivant le trajet du véhicule pour un déplacement. Conditionnellement obligatoire : - Obligatoire si le trajet a un comportement continu de prise en charge ou de dépose défini soit en `routes.txt` ou dans `stop_times.txt`. - Optionnelle autrement.
`wheelchair_accessible`	Enum	Optionnelle	Indique l'accessibilité aux fauteuils roulants. Les options valides sont : `0` ou vide - Aucune information sur l'accessibilité pour le trajet. `1` - Le véhicule utilisé pour ce trajet particulier peut accueillir au moins un passager en fauteuil roulant. `2` - Aucun voyageur en fauteuil roulant ne peut être accueilli sur ce trajet.
`bikes_allowed`	Enum	Optionnelle	Indique si les vélos sont autorisés. Les options valides sont : `0` ou vide - Aucune information sur les vélos pour ce trajet. `1` - Le véhicule utilisé pour ce trajet particulier peut accueillir au moins un vélo. `2` - Aucune bicyclette n'est autorisée sur ce trajet.

Exemple : Blocs et jour de service¶

L'exemple ci-dessous est valable, avec des blocs distincts chaque jour de la semaine.

route_id	trip_id	service_id	block_id	(first stop time)	(last stop time)
red	trip_1	mon-tues-wed-thurs-fri-sat-sun	red_loop	22:00:00	22:55:00
red	trip_2	fri-sat-sun	red_loop	23:00:00	23:55:00
red	trip_3	fri-sat	red_loop	24:00:00	24:55:00
red	trip_4	mon-tues-wed-thurs	red_loop	20:00:00	20:50:00
red	trip_5	mon-tues-wed-thurs	red_loop	21:00:00	21:50:00

Notes sur le tableau ci-dessus :

Du vendredi au samedi matin, par exemple, un seul véhicule effectue les trip_1, trip_2 et trip_3 (de 22h00 à 00h55). Notez que le dernier trajet a lieu le samedi, de minuit à minuit cinquante-cinq, mais qu'il fait partie de la " journée de service " du vendredi, car les horaires sont de minuit à minuit cinquante-cinq.
Le lundi, mardi, mercredi et jeudi, un seul véhicule effectue les trip_1, trip_4, et trip_5 dans un bloc de 20h00 à 22h55.

stop_times.txt¶

Fichier : Obligatoire

Clé primaire (trip_id, stop_sequence)

Nom du champ	Type	Présence	Description
`trip_id`	Référencement d'identifiants étrangers `trips.trip_id`	Obligatoire	Identifie un voyage.
`arrival_time`	Heure	Obligatoire sous condition	Heure d'arrivée à l'arrêt (défini par `stop_times.stop_id`) pour un trajet spécifique (défini par `stop_times.trip_id`). S'il n'y a pas d'heures séparées pour l'arrivée et le départ à un arrêt, `arrival_time` et `departure_time` devraient être les mêmes. Pour les heures se produisant après minuit le jour du service, saisissez l'heure comme une valeur supérieure à 24:00:00 en heure locale HH:MM:SS pour le jour où l'horaire du voyage commence. Si les heures d'arrivée et de départ exactes (`timepoint=1` ou vide) ne sont pas disponibles, les heures d'arrivée et de départ estimées ou interpolées (`timepoint=0`) devraient être fournies. Conditionnellement obligatoire : - Obligatoire pour le premier et le dernier arrêt d'un voyage (défini par `stop_times.stop_sequence`). - Obligatoire pour `timepoint=1`. - Optionnelle autrement.
`departure_time`	Heure	Obligatoire sous condition	Heure de départ de l'arrêt (définie par `stop_times.stop_id`) pour un trajet spécifique (défini par `stop_times.trip_id`). S'il n'y a pas d'heures distinctes pour l'arrivée et le départ à un arrêt, `arrival_time` et `departure_time` devrait être le même. Pour les heures survenant après minuit le jour du service, saisissez l'heure comme une valeur supérieure à 24:00:00 en HH:MM:SS heure locale pour le jour où l'horaire du voyage commence. Si les heures exactes d'arrivée et de départ (`timepoint=1` ou vide) ne sont pas disponibles, des heures d'arrivée et de départ estimées ou interpolées (`timepoint=0`) devraient être fournies. Conditionnellement obligatoire : - Obligatoire pour `timepoint=1`. - Optionnelle autrement.
`stop_id`	Référencement d'identifiants étrangers `stops.stop_id`	Obligatoire	Identifie l'arrêt desservi. Tous les arrêts desservis au cours d'un voyage n'ont pas d'enregistrement dans la base de données de l'entreprise. stop_times.txt. Les emplacements référencés ne doivent pas être des arrêts/plateformes, c'est-à-dire que leurs `stops.location_type` valeur doit être `0` ou vides. Un arrêt peut être desservi plusieurs fois au cours d'un même trajet, et plusieurs trajets et itinéraires peuvent desservir le même arrêt.
`stop_sequence`	Nombre entier non négatif	Obligatoire	Ordre des arrêts pour un trajet particulier. Les valeurs doivent augmenter tout au long du trajet mais ne doivent pas nécessairement être consécutives. Exemple : Le premier arrêt du trajet peut avoir une valeur de `stop_sequence`=`1`le deuxième arrêt du trajet peut avoir une valeur de `stop_sequence`=`23`le troisième arrêt peut avoir une valeur de `stop_sequence`=`40`et ainsi de suite.
`stop_headsign`	Texte	Optionnelle	Texte qui apparaît sur la signalisation identifiant la destination du voyage aux voyageurs. Ce champ remplace le champ par défaut `trips.trip_headsign` lorsque le panneau d'affichage change entre deux arrêts. Si le panneau d'affichage est affiché pendant tout un trajet, le champ devrait être utilisé à la place, `trips.trip_headsign` devrait être utilisé à la place. A `stop_headsign` valeur spécifiée pour un `stop_time` ne s'applique pas aux arrêts suivants `stop_time` suivants du même trajet. Si vous voulez remplacer les `trip_headsign` pour plusieurs `stop_time` dans le même voyage, la valeur `stop_headsign` valeur doit être répétée dans chaque `stop_time` rangée.
`pickup_type`	Enum	Optionnelle	Indique la méthode de ramassage. Les options valides sont : `0` ou vide - Ramassage programmé régulièrement. `1` - Aucun ramassage disponible. `2` - Doit téléphoner à l'agence pour organiser le ramassage. `3` - Vous devez vous mettre d'accord avec le chauffeur pour organiser le ramassage.
`drop_off_type`	Enum	Optionnelle	Indique la méthode de dépôt. Les options valides sont : `0` ou vide - Dépose programmée régulièrement. `1` - Aucun dépôt disponible. `2` - Doit téléphoner à l'agence pour organiser le dépôt. `3` - Vous devez vous mettre d'accord avec le chauffeur pour organiser la dépose.
`continuous_pickup`	Enum	Optionnelle	Indique que l'usager peut monter à bord du véhicule de transport en commun à n'importe quel point de la trajectoire du véhicule, telle que décrite par `shapes.txt`de ce site `stop_time` au suivant `stop_time` au cours du voyage `stop_sequence`. Les options valides sont : : `0` - Ramassage avec arrêt continu. `1` ou vide - Pas de ramassage avec arrêt continu. `2` - Téléphoner à l'agence pour organiser un ramassage avec arrêt continu. `3` - Veuillez vous coordonner avec le chauffeur pour organiser un ramassage avec arrêt continu. Si ce champ est renseigné, il remplace tout comportement de ramassage continu défini dans le champ `routes.txt`. Si ce champ est vide, le `stop_time` hérite de tout comportement de ramassage continu défini dans `routes.txt`.
`continuous_drop_off`	Enum	Optionnelle	Indique que l'usager peut descendre du véhicule de transport en commun à n'importe quel point de la trajectoire du véhicule, comme décrit dans le document suivant `shapes.txt`de ce `stop_time` au suivant `stop_time` dans le voyage `stop_sequence`. Les options valables sont les suivantes : : `0` - Arrêt continu de la descente. `1` ou vide - Pas d'arrêt continu. `2` - Appelez l'agence pour organiser un arrêt continu. `3` - Se coordonner avec le chauffeur pour organiser un arrêt continu. Si ce champ est rempli, il supplante tout comportement de dépose continue défini dans `routes.txt`. Si ce champ est vide, le `stop_time` hérite de tout comportement de dépose continue défini dans `routes.txt`.
`shape_dist_traveled`	Nombre flottant non négatif	Optionnelle	Distance réelle parcourue le long de la forme associée, du premier arrêt à l'arrêt spécifié dans cet enregistrement. Ce champ indique la longueur de la forme à dessiner entre deux arrêts au cours d'un trajet. Il doit être dans les mêmes unités que celles utilisées dans shapes.txt. Les valeurs utilisées pour `shape_dist_traveled` ne doivent pas augmenter avec `stop_sequence`; elles ne doivent pas être utilisées pour indiquer un trajet inverse le long d'un itinéraire. Exemple : Si un bus parcourt une distance de 5,25 kilomètres entre le début de la forme et l'arrêt,`shape_dist_traveled`=`5.25`.
`timepoint`	Enum	Optionnelle	Indique si les heures d'arrivée et de départ d'un arrêt sont strictement respectées par le véhicule ou s'il s'agit plutôt d'heures approximatives et/ou interpolées. Ce champ permet à un producteur GTFS de fournir des heures d'arrêt interpolées, tout en indiquant que les heures sont approximatives. Les options valides sont les suivantes : `0` - Les temps sont considérés comme approximatifs. `1` ou vide - Les temps sont considérés comme exacts.

calendar.txt¶

Fichier : Conditionally Obligatoire

Clé primaire (service_id)

Nom du champ	Type	Présence	Description
`service_id`	Unique ID	Obligatoire	Identifie un ensemble de dates où le service est disponible pour un ou plusieurs itinéraires. Chaque valeur `service_id` valeur doit être unique dans un calendar.txt fichier.
`monday`	Enum	Obligatoire	Indique si le service fonctionne tous les lundis dans la plage de dates spécifiée par les champs `start_date` et `end_date` champs. Notez que les exceptions pour des dates particulières peuvent être énumérées dans les champs suivants calendar_dates.txt. Les options valides sont : : `1` - Le service est disponible pour tous les lundis de la plage de dates. `0` - Le service n'est pas disponible pour les lundis de la plage de dates.
`tuesday`	Enum	Obligatoire	Fonctionne de la même manière que `monday` sauf pour les mardis
`wednesday`	Enum	Obligatoire	Fonctions identiques à celles de `monday` sauf pour les mercredis
`thursday`	Enum	Obligatoire	Fonctions de la même manière que `monday` sauf pour les jeudis
`friday`	Enum	Obligatoire	Fonctions de la même manière que `monday` sauf pour les vendredis
`saturday`	Enum	Obligatoire	Fonctions de la même manière que `monday` sauf pour les samedis.
`sunday`	Enum	Obligatoire	Fonctions de la même manière que `monday` sauf s'applique aux dimanches.
`start_date`	Date	Obligatoire	Jour de début d'entretien pour l'intervalle d'entretien.
`end_date`	Date	Obligatoire	Jour de fin d'entretien pour l'intervalle d'entretien. Ce jour de service est inclus dans l'intervalle.

calendar_dates.txt¶

Fichier : Conditionally Obligatoire

Clé primaire (service_id, date)

Le tableau calendar_dates.txt active ou désactive explicitement le service par date. Il peut être utilisé de deux manières.

Recommandé : Utilisez calendar_dates.txt en conjonction avec calendar.txt pour définir des exceptions aux modèles de service par défaut définis dans calendar.txt. Si le service est généralement régulier, avec quelques changements à des dates explicites (par exemple, pour s'adapter à des services d'événements spéciaux, ou à un calendrier scolaire), c'est une bonne approche. Dans ce cas, calendar_dates.service_id est un ID étranger faisant référence à calendar.service_id.
Autre solution : Omettre calendar.txt, et spécifier chaque date de service dans calendar_dates.txt. Cela permet de varier considérablement les services et de s'adapter aux services sans horaires hebdomadaires normaux. Dans ce cas, service_id est un ID.

Nom du champ	Type	Présence	Description
`service_id`	Référencement d'identifiants étrangers `calendar.service_id` ou ID	Obligatoire	Identifie un ensemble de dates où une exception de service se produit pour une ou plusieurs routes. Chaque paire (`service_id`, `date`) ne peut apparaître qu'une seule fois dans calendar_dates.txt si vous utilisez calendar.txt et calendar_dates.txt en conjonction. Si une valeur `service_id` apparaît à la fois dans calendar.txt et calendar_dates.txt l'information contenue dans calendar_dates.txt modifie les informations de service spécifiées dans calendar.txt.
`date`	Date	Obligatoire	Date à laquelle le service fait exception.
`exception_type`	Enum	Obligatoire	Indique si le service est disponible à la date spécifiée dans le champ date. Les options valides sont : `1` - Le service a été ajouté pour la date spécifiée. `2` - Le service a été supprimé pour la date spécifiée. Exemple : Supposons qu'un itinéraire comporte un ensemble de trajets disponibles les jours fériés et un autre ensemble de trajets disponibles tous les autres jours. L'un des sites `service_id` pourrait correspondre à l'horaire de service régulier et un autre `service_id` pourrait correspondre à l'horaire des jours fériés. Pour un jour férié particulier, l'horaire calendar_dates.txt pourrait être utilisé pour ajouter le jour férié à l'horaire de vacances `service_id` et pour retirer le jour férié de l'horaire régulier `service_id` horaire.

fare_attributes.txt¶

Fichier : Optionnelle

Clé primaire (fare_id)

Versions
Il existe deux options de modélisation pour décrire les tarifs. GTFS V1 est l'ancienne option pour décrire les informations tarifaires minimales. GTFS V2 est une méthode actualisée qui permet un compte rendu plus détaillé de la structure tarifaire d'une agence. Les deux méthodes peuvent être présentes dans un ensemble de données, mais une seule méthode devrait être utilisée par un consommateur de données pour un ensemble de données donné. Il est recommandé que GTFS V2 ait la priorité sur GTFS V1.

Les fichiers associés à GTFS V1 sont :
- fare_attributes.txt
- fare_rules.txt

Les fichiers associés à GTFS V2 sont :
- fare_media.txt
-fare_products.txt
- fare_leg_rules.txt
- fare_transfer_rules.txt

Nom du champ	Type	Présence	Description
`fare_id`	Unique ID	Obligatoire	Identifie une classe tarifaire.
`price`	Nombre flottant non négatif	Obligatoire	Prix du tarif, dans l'unité spécifiée par `currency_type`.
`currency_type`	Code devise	Obligatoire	Monnaie utilisée pour payer le tarif.
`payment_method`	Enum	Obligatoire	Indique quand le tarif doit être payé. Les options valides sont les suivantes : `0` - Le tarif est payé à bord. `1` - Le tarif doit être payé avant l'embarquement.
`transfers`	Enum	Obligatoire	Indique le nombre de transferts autorisés pour ce tarif. Les options valables sont les suivantes : `0` - Aucun transfert n'est autorisé pour ce tarif. `1` - Les passagers peuvent être transférés une fois. `2` - Les passagers peuvent être transférés deux fois. empty - Les transferts illimités sont autorisés.
`agency_id`	Référencement d'identifiants étrangers `agency.agency_id`	Obligatoire sous condition	Identifie l'agence concernée par un tarif. Conditionnellement obligatoire : - Obligatoire si plusieurs agences sont définies dans `agency.txt`. - Optionnelle autrement.
`transfer_duration`	Entier non négatif	Optionnelle	Durée en secondes avant l'expiration d'un transfert. Sur `transfers`=`0` ce champ peut être utilisé pour indiquer la durée de validité d'un billet ou peut être laissé vide.

fare_rules.txt¶

Fichier : Optionnelle

Clé primaire (*)

La table fare_rules.txt spécifie comment les tarifs dans fare_attributes.txt s'appliquent à un itinéraire. La plupart des structures tarifaires utilisent une combinaison des règles suivantes :

Le tarif dépend des gares d'origine ou de destination.
Le tarif dépend des zones traversées par l'itinéraire.
Le tarif dépend de la route utilisée par l'itinéraire.

Pour des exemples démontrant comment spécifier une structure tarifaire avec fare_rules.txt et fare_attributes.txt, voir FareExamples dans le wiki du projet open source GoogleTransitDataFeed.

Nom du champ	Type	Présence	Description
`fare_id`	Référencement d'identifiants étrangers `fare_attributes.fare_id`	Obligatoire	Identifie une classe tarifaire.
`route_id`	Référencement d'identifiants étrangers `routes.route_id`	Optionnelle	Identifie un itinéraire associé à la classe tarifaire. Si plusieurs itinéraires avec les mêmes attributs tarifaires existent, créez un enregistrement dans le fichier fare_rules.txt pour chaque ligne. Exemple : Si la classe tarifaire "b" est valable sur les lignes "TSW" et "TSE", la classe tarifaire "b" est valable sur la ligne "TSW". fare_rules.txt Ce fichier contiendrait ces enregistrements pour la classe tarifaire : `fare_id,route_id` `b,TSW` `b,TSE`
`origin_id`	Référencement d'identifiants étrangers `stops.zone_id`	Optionnelle	Identifie une zone d'origine. Si une classe tarifaire comporte plusieurs zones d'origine, créer un enregistrement dans le fichier fare_rules.txt pour chacun `origin_id`. Exemple : Si la classe tarifaire "b" est valable pour tous les déplacements au départ de la zone "2" ou de la zone "8", les champs fare_rules.txt Le fichier contiendrait ces enregistrements pour la classe tarifaire : `fare_id,...,origin_id` `b,...,2` `b,...,8`
`destination_id`	Référencement d'identifiants étrangers `stops.zone_id`	Optionnelle	Identifie une zone de destination. Si une classe tarifaire a plusieurs zones de destination, créez un enregistrement dans la zone de destination. fare_rules.txt pour chaque `destination_id`. exemple : Le site `origin_id` et `destination_id` peuvent être utilisés ensemble pour spécifier que la classe tarifaire "b" est valable pour les trajets entre les zones 3 et 4, et pour les trajets entre les zones 3 et 5, les champs fare_rules.txt Le fichier contiendrait ces enregistrements pour la classe tarifaire : `fare_id,...,origin_id,destination_id` `b,...,3,4` `b,...,3,5`
`contains_id`	Référencement d'identifiants étrangers `stops.zone_id`	Optionnelle	Identifie les zones dans lesquelles un usager entrera lorsqu'il utilisera une classe tarifaire donnée. Utilisé dans certains systèmes pour calculer la classe tarifaire correcte. Exemple : Si la classe tarifaire "c" est associée à tous les déplacements sur l'itinéraire du GRT qui passe par les zones 5, 6 et 7, les zones fare_rules.txt La base de données contient ces enregistrements : `fare_id,route_id,...,contains_id` `c,GRT,...,5` `c,GRT,...,6` `c,GRT,...,7` Parce que tous les `contains_id` Les zones doivent correspondre pour que le tarif s'applique, un itinéraire qui passe par les zones 5 et 6 mais pas par la zone 7 n'aurait pas la classe tarifaire "c". Pour plus de détails, voir https://code.google.com/p/googletransitdatafeed/wiki/FareExamples dans le wiki du projet GoogleTransitDataFeed.

fare_media.txt¶

Fichier: Optional

Clé primaire (fare_media_id)

Décrire les différents supports tarifaires qui peuvent être utilisés pour utiliser les produits tarifaires. Les supports tarifaires sont des supports physiques ou virtuels utilisés pour la représentation et/ou la validation d'un produit tarifaire.

Nom du champ	Type	Présence	Description
`fare_media_id`	ID unique	Requis	Identifie un support tarifaire.
`fare_media_name`	Texte	Optionnel	Nom du support tarifaire. Pour les supports tarifaires qui sont des cartes de transport (`fare_media_type =2`) ou des applications mobiles (`fare_media_type =4`), le nom `fare_media_name` devrait être inclus et devrait correspondre au nom utilisé par les organisations qui les distribuent.
`fare_media_type`	enum	Requis	Type de support tarifaire. Les options valides sont les suivantes : `0` - Aucun. Utilisé lorsqu'il n'y a pas de support tarifaire impliqué dans l'achat ou la validation d'un produit tarifaire, comme le paiement en espèces à un conducteur ou à un chef de train sans billet physique fourni. `2` - Carte de transport physique sur laquelle sont stockés des billets, des laissez-passer ou une valeur monétaire. `3` - cEMV (Europay, Mastercard et Visa sans contact) en tant que conteneur de jetons en boucle ouverte pour la billetterie basée sur le compte. `4` - Application mobile qui a stocké des cartes de transport virtuelles, des billets, des laissez-passer ou une valeur monétaire.

fare_products.txt¶

Fichier : Optionnelle

Clé primaire (fare_product_id, fare_media_id)

Décrire les différents types de billets ou de tarifs qui peuvent être achetés par les usagers.

Nom du champ	Type	Présence	Description
`fare_product_id`	ID	Obligatoire	Identifie un produit tarifaire.
`fare_product_name`	Texte	Optionnelle	Le nom du produit tarifaire tel qu'il est affiché aux usagers.
`fare_media_id`	Référencement d'identifiants étrangers `fare_media.fare_media_id`	Optionnelle	Identifie un support tarifaire qui peut être employé pour utiliser le produit tarifaire au cours du voyage. Lorsque `fare_media_id` est vide, on considère que le support tarifaire est inconnu.
`amount`	Montant en devise	Obligatoire	Le coût du produit tarifaire. Peut être négatif pour représenter les réductions de transfert. Peut être zéro pour représenter un produit tarifaire gratuit.
`currency`	Code de la devise	Obligatoire	La devise du coût du produit tarifaire.

fare_leg_rules.txt¶

Fichier : Optionnelle

Clé primaire (network_id, from_area_id, to_area_id, fare_product_id)

Les règles tarifaires pour des trajets individuels.

Les tarifs figurant dans le fichier fare_leg_rules.txt ne peuvent être interrogés en filtrant tous les enregistrements du fichier afin de trouver les règles qui correspondent au segment que le voyageur doit parcourir.

Pour traiter le coût d'un segment :

Le fichier fare_leg_rules.txt doit être filtré par les champs qui définissent les caractéristiques du voyage, ces champs sont :
fare_leg_rules.network_id
fare_leg_rules.from_area_id
fare_leg_rules.to_area_id
Si le segment correspond exactement à un enregistrement dans fare_leg_rules.txt en fonction des caractéristiques du voyage, cet enregistrement doit être traité pour déterminer le coût du segment.
Si aucune correspondance exacte n'est trouvée, les entrées vides dans fare_leg_rules.network_id, fare_leg_rules.from_area_id et fare_leg_rules.to_area_id doivent être vérifiées pour traiter le coût du segment :
Une entrée vide dans fare_leg_rules.network_id correspond à tous les réseaux définis dans routes.txt, à l'exception de ceux énumérés dans fare_leg_rules.network_id.
Une entrée vide dans fare_leg_rules.from_area_id correspond à toutes les zones définies dans areas.area_id à l'exclusion de celles énumérées dans fare_leg_rules.from_area_id
Une entrée vide dans fare_leg_rules.to_area_id correspond à toutes les zones définies dans areas.area_id l'exclusion de ceux énumérés sous fare_leg_rules.to_area_id

Si le segment ne correspond à aucune des règles décrites ci-dessus, alors le tarif est inconnu.

Nom du champ	Type	Présence	Description
`leg_group_id`	ID	Optionnelle	Identifie un groupe d'entrées dans fare_leg_rules.txt. Utilisé pour décrire les règles de transfert des tarifs entre `fare_transfer_rules.from_leg_group_id` et `fare_transfer_rules.to_leg_group_id`. Des entrées multiples dans fare_leg_rules.txt peuvent appartenir à la même `fare_leg_rules.leg_group_id`. La même entrée dans fare_leg_rules.txt (ne comprenant pas `fare_leg_rules.leg_group_id`) ne peut pas appartenir à plusieurs `fare_leg_rules.leg_group_id`.
`network_id`	Référencement d'identifiants étrangers `routes.network_id`	Optionnelle	Identifie un réseau de routes qui s'applique à la règle du segment tarifaire. S'il n'y a pas de correspondance `fare_leg_rules.network_id` valeurs pour le `network_id` en cours de filtrage, vide `fare_leg_rules.network_id` seront mis en correspondance par défaut. Une entrée vide dans `fare_leg_rules.network_id` correspond à tous les réseaux définis dans `routes.txt` à l'exclusion de ceux énumérés sous `fare_leg_rules.network_id`
`from_area_id`	Référencement d'identifiants étrangers `areas.area_id`	Optionnelle	Identifie une zone de départ. S'il n'y a pas de correspondance `fare_leg_rules.from_area_id` valeurs de la `area_id` filtré, vide `fare_leg_rules.from_area_id` sera appariée par défaut. Une entrée vide dans `fare_leg_rules.from_area_id` correspond à toutes les zones définies dans `areas.area_id` à l'exclusion de ceux énumérés sous `fare_leg_rules.from_area_id`.
`to_area_id`	Référencement d'identifiants étrangers `areas.area_id`	Optionnelle	Identifie une zone d'arrivée. S'il n'y a pas de correspondance `fare_leg_rules.to_area_id` valeurs de la `area_id` étant filtré, vide `fare_leg_rules.to_area_id` sera traité par défaut. Une entrée vide dans `fare_leg_rules.to_area_id` correspond à toutes les zones définies dans `areas.area_id` à l'exclusion de ceux énumérés sous `fare_leg_rules.to_area_id`
`fare_product_id`	Référencement d'identifiants étrangers `fare_products.fare_product_id`	Obligatoire	Le produit tarifaire obligatoire pour voyager sur le segment.

fare_transfer_rules.txt¶

Fichier : Optionnelle

Clé primairefrom_leg_group_id, to_leg_group_id, fare_product_id, transfer_count, duration_limit)

Les règles tarifaires pour les transferts entre les segments de voyage sont définies dans fare_leg_rules.txt.

Pour traiter le coût d'un voyage à plusieurs étapes :

Les groupes de segments tarifaires applicables définis dans fare_leg_rules.txt devraient être déterminés pour tous les segments individuels du voyage en fonction du trajet du coureur.
Le fichier fare_transfer_rules.txt doit être filtré par les champs qui définissent les caractéristiques du transfert, ces champs sont :
- fare_transfer_rules.from_leg_group_id
- fare_transfer_rules.to_leg_group_id
Si le transfert correspond exactement à un enregistrement dans fare_transfer_rules.txt en fonction des caractéristiques du transfert, alors cet enregistrement doit être traité pour déterminer le coût du transfert.
Si aucune correspondance exacte n'est trouvée, les entrées vides dans from_leg_group_id ou dans to_leg_group_id doivent être vérifiées pour calculer le coût du transfert :
- Une entrée vide dans fare_transfer_rules.from_leg_group_id correspond à tous les groupes de segments définis dans fare_leg_rules.leg_group_id, à l'exclusion de ceux énumérés dans fare_transfer_rules.from_leg_group_id.
- Une entrée vide dans fare_transfer_rules.to_leg_group_id correspond à tous les groupes de segments définis dans fare_leg_rules.leg_group_id, à l'exception de ceux énumérés dans fare_transfer_rules.to_leg_group_id
Si le transfert ne correspond à aucune des règles décrites ci-dessus, il n'y a pas d'arrangement de transfert et les segments sont considérés comme distincts.

Nom du champ Type Présence Description

from_leg_group_id Référencement d'identifiants étrangers fare_leg_rules.leg_group_id Optionnelle Identifie un groupe de règles de segment tarifaire pré-transfert.

S'il n'y a pas de correspondance fare_transfer_rules.from_leg_group_id valeurs de la leg_group_id étant filtré, vide fare_transfer_rules.from_leg_group_id La correspondance se fera par défaut.

Une entrée vide dans fare_transfer_rules.from_leg_group_id correspond à tous les groupes de segments définis sous fare_leg_rules.leg_group_id à l'exclusion de ceux qui sont énumérés sous fare_transfer_rules.from_leg_group_id.

to_leg_group_id Référencement d'identifiants étrangers fare_leg_rules.leg_group_id Optionnelle Identifie un groupe de règles de segment tarifaire post-transfert.

S'il n'y a pas de correspondance fare_transfer_rules.to_leg_group_id valeurs de la leg_group_id étant filtré, vide fare_transfer_rules.to_leg_group_id sera traité par défaut.

Une entrée vide dans fare_transfer_rules.to_leg_group_id correspond à tous les groupes de segments définis sous fare_leg_rules.leg_group_id à l'exclusion de ceux énumérés sous fare_transfer_rules.to_leg_group_id.

transfer_count Nombre entier non nul Interdit sous condition Définit le nombre de transferts consécutifs auxquels la règle de transfert peut s'appliquer.

Les options valides sont :
-1 - Aucune limite.
1 ou plus - Définit le nombre de transferts que la règle de transfert peut couvrir.

Si un sous-voyageur correspond à plusieurs enregistrements avec différents transfer_countdifférents, alors la règle dont le minimum transfer_count qui est supérieure ou égale au nombre de transferts actuels du sous-voyage doit être sélectionnée.

Interdit sous condition :
- Interdit si fare_transfer_rules.from_leg_group_id n'est pas égal fare_transfer_rules.to_leg_group_id.
- Obligatoire si fare_transfer_rules.from_leg_group_id est égal à fare_transfer_rules.to_leg_group_id.

duration_limit Entier positif Optionnelle Définit la limite de durée du transfert.

Elle doit être exprimée en incréments entiers de secondes.

S'il n'y a pas de limite de durée, fare_transfer_rules.duration_limit ne doit pas être vide.

duration_limit_type Enum Obligatoire sous condition Définit le début et la fin relatifs de fare_transfer_rules.duration_limit.

Les options valides sont : :
0 - Entre la validation du tarif de départ du segment en cours et la validation du tarif d'arrivée du segment suivant.
1 - Entre la validation du tarif de départ du segment en cours et la validation du tarif de départ du segment suivant.
2 - Entre la validation du tarif d'arrivée du segment en cours et la validation du tarif de départ du segment suivant.
3 - Entre la validation du tarif d'arrivée du segment en cours et la validation du tarif d'arrivée du segment suivant.

Conditionnellement obligatoire :
- Obligatoire si fare_transfer_rules.duration_limit est défini.
- Interdit si fare_transfer_rules.duration_limit est vide.

fare_transfer_type

Enum

Obligatoire

Indique la méthode de traitement des coûts pour le transfert entre les étapes d'un voyage :

Les options valides sont :
0 - De-jambe fare_leg_rules.fare_product_id plus fare_transfer_rules.fare_product_id; A + AB.
1 - De-l'étape fare_leg_rules.fare_product_id plus fare_transfer_rules.fare_product_id plus to-leg fare_leg_rules.fare_product_id; A + AB + B.
2 - fare_transfer_rules.fare_product_id; AB.

Traitement du coût des interactions entre plusieurs transferts dans un trajet :

`fare_transfer_type`	Traitement A > B	Traitement B > C
`0`	A + AB	S + BC
`1`	A + AB +B	S + BC + C
`2`	AB	S + BC

Où S indique le coût total traité du ou des tronçons précédents et du ou des transferts.

fare_product_id Référencement d'identifiants étrangers fare_products.fare_product_id Optionnelle Le produit tarifaire obligatoire pour le transfert entre deux segments tarifaires. S'il est vide, le coût de la règle de transfert est égal à 0.

areas.txt¶

Dossier : Optionnelle

Clé primaire (area_id)

Définit les identifiants de zone.

Nom du champ	Type	Présence	Description
`area_id`	Unique ID	Obligatoire	Identifie une zone. Doit être unique dans areas.txt.
`area_name`	Texte	Optionnelle	Le nom de la zone tel qu'il est affiché au coureur.

stop_areas.txt¶

Fichier : Optionnelle

Clé primaire (*)

Affecte les arrêts du fichier stops.txt aux zones.

Nom du champ	Type	Présence	Description
`area_id`	Référencement d'identifiants étrangers `areas.area_id`	Obligatoire	Identifie une zone à laquelle un ou plusieurs `stop_id`appartiennent. Le même `stop_id` peut être défini dans plusieurs `area_id`s.
`stop_id`	Référencement d'identifiants étrangers `stops.stop_id`	Obligatoire	Identifie un arrêt. Si une station (c'est-à-dire un arrêt avec `stops.location_type=1`) est définie dans ce champ, il est supposé que toutes ses plateformes (c'est-à-dire tous les arrêts avec `stops.location_type=0` qui ont cette station définie comme `stops.parent_station`) font partie de la même zone. Ce comportement peut être remplacé par l'affectation de plates-formes à d'autres zones.

shapes.txt¶

Fichier : Optionnelle

Clé primaire (shape_id, shape_pt_sequence)

Les formes décrivent le chemin que parcourt un véhicule le long d'un alignement d'itinéraire, et sont définies dans le fichier shapes.txt. Les Shapes sont associés aux Trips, et consistent en une séquence de points par lesquels le véhicule passe dans l'ordre. Les formes n'ont pas besoin d'intercepter exactement l'emplacement des arrêts, mais tous les arrêts d'un trajet devraient se trouver à une petite distance de la forme pour ce trajet, c'est-à-dire à proximité des segments de ligne droite reliant les points de la forme.

Nom du champ	Type	Présence	Description
`shape_id`	ID	Obligatoire	Identifie une forme.
`shape_pt_lat`	Latitude	Obligatoire	Latitude d'un point de la forme. Chaque enregistrement dans shapes.txt représente un point de forme utilisé pour définir la forme.
`shape_pt_lon`	Longitude	Obligatoire	Longitude d'un point de forme.
`shape_pt_sequence`	Nombre entier non négatif	Obligatoire	Séquence dans laquelle les points de forme se connectent pour former la forme. Les valeurs doivent augmenter le long du trajet mais ne doivent pas nécessairement être consécutives. Exemple : Si la forme "A_shp" a trois points dans sa définition, le fichier shapes.txt Le fichier peut contenir ces enregistrements pour définir la forme : `shape_id,shape_pt_lat,shape_pt_lon,shape_pt_sequence` `A_shp,37.61956,-122.48161,0` `A_shp,37.64430,-122.41070,6` `A_shp,37.65863,-122.30839,11`
`shape_dist_traveled`	Nombre flottant non négatif	Optionnelle	La distance réelle parcourue le long de la forme entre le premier point de la forme et le point spécifié dans cet enregistrement. Utilisé par les planificateurs de voyage pour montrer la partie correcte de la forme sur une carte. Les valeurs n'augmentent pas avec `shape_pt_sequence`elles ne doivent pas être utilisées pour montrer un voyage inverse le long d'un itinéraire. Les unités de distance doivent être cohérentes avec celles utilisées dans la base de données. stop_times.txt. Exemple : Si un bus se déplace le long des trois points définis ci-dessus pour A_shp, les valeurs supplémentaires `shape_dist_traveled` valeurs supplémentaires (indiquées ici en kilomètres) ressembleraient à ceci : `shape_id,shape_pt_lat,shape_pt_lon,shape_pt_sequence,shape_dist_traveled` `A_shp,37.61956,-122.48161,0,0` `A_shp,37.64430,-122.41070,6,6.8310` `A_shp,37.65863,-122.30839,11,15.8765`

frequencies.txt¶

Fichier : Optionnelle

Clé primaire (trip_id, start_time)

frequencies.txt représente les trajets qui fonctionnent avec des intervalles réguliers (temps entre les trajets). Ce fichier peut être utilisé pour représenter deux types de service différents.

Service basé sur la fréquence(exact_times=0) dans lequel le service ne suit pas un horaire fixe tout au long de la journée. Au lieu de cela, les opérateurs tentent de maintenir strictement des intervalles de passage prédéterminés pour les trajets.
Une représentation comprimée du service basé sur les horaires(exact_times=1) qui a exactement le même intervalle de temps pour les trajets sur une ou plusieurs périodes de temps spécifiées. Dans un service basé sur les horaires, les opérateurs essaient de respecter strictement un horaire.

Nom du champ	Type	Présence	Description
`trip_id`	Référencement d'identifiants étrangers `trips.trip_id`	Obligatoire	Identifie un trajet auquel s'applique l'intervalle de service spécifié.
`start_time`	Heure	Obligatoire	Heure à laquelle le premier véhicule quitte le premier arrêt du trajet avec l'intervalle de passage spécifié.
`end_time`	Heure	Obligatoire	Heure à laquelle le service passe à un intervalle différent (ou cesse) au premier arrêt du trajet.
`headway_secs`	Nombre entier positif	Obligatoire	Temps, en secondes, entre les départs du même arrêt (intervalle de passage) pour le trajet, pendant l'intervalle de temps spécifié par `start_time` et `end_time`. Plusieurs points d'arrêt peuvent être définis pour le même trajet, mais ils ne doivent pas se chevaucher. Les nouveaux passages peuvent commencer au moment exact où le passage précédent se termine.
`exact_times`	Enum	Optionnelle	Indique le type de service pour un trajet. Voir la description du fichier pour plus d'informations. Les options valides sont : `0` ou vide - Trajets basés sur la fréquence. `1` - Il s'agit de trajets basés sur les horaires avec exactement le même intervalle de passage tout au long de la journée. Dans ce cas, la valeur `end_time` valeur doit être supérieure au dernier trajet souhaité `start_time` mais inférieure à l'start_time dernier trajet souhaité +. `headway_secs`.

transfers.txt¶

Fichier : Optionnelle

Clé primaire (from_stop_id, to_stop_id, from_trip_id, to_trip_id, from_route_id, to_route_id)

Lors du calcul d'un itinéraire, les applications GTFS interpolent les transferts en fonction du temps autorisé et de la proximité des arrêts. transfers.txt spécifie des règles et des surcharges supplémentaires pour les transferts sélectionnés.

Les champs from_trip_id, to_trip_id, from_route_id et to_route_id permettent des niveaux de spécificité plus élevés pour les règles de transfert. Avec from_stop_id et to_stop_id, le classement de la spécificité est le suivant :

Les deux trip_iddéfinis : from_trip_id et to_trip_id.
Un ensemble de trip_id et route_id défini : from_trip_id et to_route_id) oufrom_route_id et to_trip_id).
Un trip_id défini : from_trip_id ou to_trip_id.
Les deux route_id définis : from_route_id et to_route_id.
Un seul route_id défini : from_route_id ou to_route_id.
Seuls from_stop_id et to_stop_id sont définis : aucun champ relatif à l'itinéraire ou au voyage n'est défini.

Pour une paire ordonnée donnée de voyage d'arrivée et de voyage de départ, le transfert avec la plus grande spécificité qui s'applique entre ces deux voyages est choisi. Pour toute paire de trajets, il ne devrait pas y avoir deux transferts avec la même spécificité maximale qui pourraient s'appliquer.

Nom du champ	Type	Présence	Description
`from_stop_id`	Référencement d'identifiants étrangers `stops.stop_id`	Obligatoire	Identifie un arrêt ou une station où commence une connexion entre des trajets. Si ce champ fait référence à une station, la règle de transfert s'applique à tous ses arrêts enfants.
`to_stop_id`	Référencement d'identifiants étrangers `stops.stop_id`	Obligatoire	Identifie un arrêt ou une station où se termine une connexion entre des itinéraires. Si ce champ fait référence à une station, la règle de transfert s'applique à tous les arrêts enfants.
`from_route_id`	Référencement d'identifiants étrangers `routes.route_id`	Optionnelle	Identifie un itinéraire où commence une connexion. Si `from_route_id` Si ce champ est défini, le transfert s'applique au trajet arrivant sur l'itinéraire pour l'arrêt donné. `from_stop_id`. Si les deux `from_trip_id` et `from_route_id` sont définis, le transfert `trip_id` doit appartenir à la `route_id`, et `from_trip_id` auront la priorité.
`to_route_id`	Référencement d'identifiants étrangers `routes.route_id`	Optionnelle	Identifie un itinéraire où se termine une correspondance. Si `to_route_id` Si une correspondance est définie, le transfert s'appliquera au trajet de départ sur l'itinéraire pour le trajet donné. `to_stop_id`. Si les deux `to_trip_id` et `to_route_id` sont définis, les `trip_id` doit appartenir à la `route_id`, et `to_trip_id` aura la priorité.
`from_trip_id`	Référencement d'identifiants étrangers `trips.trip_id`	Optionnelle	Identifie un trajet où commence une connexion entre des itinéraires. Si `from_trip_id` est défini, le transfert s'appliquera au voyage arrivant pour le trajet donné. `from_stop_id`. Si les deux `from_trip_id` et `from_route_id` sont définis, les `trip_id` doit appartient à la `route_id`et `from_trip_id` aura la priorité.
`to_trip_id`	Référencement d'identifiants étrangers `trips.trip_id`	Optionnelle	Identifie un trajet où une connexion entre les routes se termine. Si `to_trip_id` Si le transfert est défini, il s'appliquera au trajet de départ pour le trajet donné. `to_stop_id`. Si les deux `to_trip_id` et `to_route_id` sont définis, le `trip_id` doit appartenir au `route_id`et `to_trip_id` sera prioritaire.
`transfer_type`	Enum	Obligatoire	Indique le type de connexion pour la paire (`from_stop_id`, `to_stop_id`) spécifié. Les options valides sont `0` ou vide - Point de transfert recommandé entre les itinéraires. `1` - Point de transfert programmé entre deux itinéraires. Le véhicule qui part est censé attendre celui qui arrive et laisser suffisamment de temps à l'usager pour effectuer le transfert entre les itinéraires. `2` - Le transfert nécessite un temps minimum entre l'arrivée et le départ pour assurer une correspondance. Le temps obligatoire pour le transfert est spécifié par `min_transfer_time`. `3` - Les transferts ne sont pas possibles entre les itinéraires à cet endroit.
`min_transfer_time`	Nombre entier non négatif	Optionnelle	Le temps, en secondes, qui doit être disponible pour permettre un transfert entre les lignes aux arrêts spécifiés. Le site `min_transfer_time` devrait être suffisant pour permettre à un usager type de se déplacer entre les deux arrêts, y compris un temps tampon pour tenir compte des variations d'horaires sur chaque itinéraire.

pathways.txt¶

Fichier : Optionnelle

Clé primaire (pathway_id)

Les fichiers pathways.txt et levels.txt utilisent une représentation graphique pour décrire les stations de métro ou de train, les nœuds représentant les emplacements et les arêtes les chemins.

Pour naviguer de l'entrée/sortie de la station (un noeud représenté comme un emplacement avec location_type=2) à un quai (un noeud représenté comme un emplacement avec location_type=0 ou vide), l'usager se déplacera à travers des passerelles, des barrières tarifaires, des escaliers et d'autres bords représentés comme des sentiers. Les noeuds génériques (noeuds représentés par le type d'emplacement = 3) peuvent être utilisés pour relier les chemins dans une station.

Les chemins ne doivent pas être définis de manière exhaustive dans une station. Si des cheminements sont définis, on suppose que tous les cheminements de la station sont représentés. Par conséquent, les directives suivantes s'appliquent :

Pas d'emplacements suspendus : Si un emplacement dans une station a un cheminement, alors tous les emplacements dans cette station devraient avoir des cheminements, sauf pour les plates-formes qui ont des zones d'embarquement(location_type=4, voir la directive ci-dessous).
Aucun cheminement pour un quai avec des zones d'embarquement : Une plateforme(location_type=0 ou vide) qui a des zones d'embarquement(location_type=4) est traitée comme un objet parent, pas comme un point. Dans ce cas, la plateforme ne doit pas avoir de chemins assignés. Toutes les voies doivent être attribuées pour chacune des zones d'embarquement de la plate-forme.
Pas de plateformes verrouillées : Chaque plateforme(location_type=0 ou vide) ou zone d'embarquement(location_type=4) doit être connectée à au moins une entrée/sortie(location_type=2) via une chaîne de chemins. Les stations qui ne permettent pas d'accéder à l'extérieur de la station depuis un quai donné sont rares.

Nom du champ	Type	Présence	Description
`pathway_id`	Unique ID	Obligatoire	Identifie une voie d'accès. Utilisé par les systèmes comme un identifiant interne pour l'enregistrement. Il doit être unique dans l'ensemble de données. Différents parcours peuvent avoir les mêmes valeurs pour `from_stop_id` et `to_stop_id`. Exemple : Lorsque deux escalators sont côte à côte dans des directions opposées, ou lorsqu'une cage d'escalier et un ascenseur vont du même endroit au même endroit, différents. `pathway_id` peuvent avoir le même `from_stop_id` et `to_stop_id` valeurs.
`from_stop_id`	Référencement d'identifiants étrangers `stops.stop_id`	Obligatoire	L'endroit où commence le parcours. Doit-il contenir un `stop_id` qui identifie une plate-forme (`location_type=0` ou vide), une entrée/sortie (`location_type=2`), un nœud générique (`location_type=3`) ou zone d'embarquement (`location_type=4`). Valeurs pour `stop_id` qui identifient les stations (`location_type=1`) sont interdites.
`to_stop_id`	Référencement d'identifiants étrangers `stops.stop_id`	Obligatoire	Emplacement auquel le chemin se termine. Doit-il contenir un `stop_id` qui identifie une plate-forme (`location_type=0` ou vide), une entrée/sortie (`location_type=2`), nœud générique (`location_type=3`) ou zone d'embarquement (`location_type=4`). Valeurs pour `stop_id` qui identifient les stations (`location_type=1`) sont interdites.
`pathway_mode`	Enum	Obligatoire	Type de chemin d'accès entre la paire (`from_stop_id`, `to_stop_id`) spécifiée. Les options valides sont les suivantes : `1` - Passerelle. `2` - Escalier. `3` - Trottoir mobile/travelator. `4` - Escalier roulant. `5` - Ascenseur. `6` - Porte tarifaire (ou porte de paiement) : Un passage qui traverse une zone de la station où la preuve de paiement est obligatoire pour traverser. Les portes tarifaires peuvent séparer les zones payantes de la station des zones non payantes, ou séparer différentes zones de paiement au sein d'une même station. Ces informations peuvent être utilisées pour éviter d'acheminer les passagers dans les stations en utilisant des raccourcis qui obligeraient les passagers à effectuer des paiements inutiles, comme par exemple demander à un passager de traverser un quai de métro pour atteindre un bus. `7`- Porte de sortie : Un chemin sortant d'une zone payante vers une zone non payante où la preuve de paiement n'est pas obligatoire pour traverser.
`is_bidirectional`	Enum	Obligatoire	Indique la direction dans laquelle le sentier peut être emprunté : `0` - Sentier unidirectionnel qui ne peut être emprunté qu'à partir de... `from_stop_id` à `to_stop_id`. `1` - Sentier bidirectionnel qui peut être utilisé dans les deux sens. Les portes de sortie (`pathway_mode=7`) ne doivent pas être bidirectionnelles.
`length`	Flottant non négatif	Optionnelle	Longueur horizontale, en mètres, du sentier entre l'emplacement d'origine (défini en `from_stop_id`) à l'emplacement de destination (défini en `to_stop_id`). Ce champ est recommandé pour les passerelles (`pathway_mode=1`), les portes d'entrée (`pathway_mode=6`) et les portes de sortie (`pathway_mode=7`).
`traversal_time`	Entier positif	Optionnelle	Temps moyen en secondes nécessaire pour parcourir le cheminement depuis le lieu d'origine (défini en `from_stop_id`) à l'emplacement de destination (défini en `to_stop_id`). Ce champ est recommandé pour les trottoirs roulants (`pathway_mode=3`), les escaliers mécaniques (`pathway_mode=4`) et les ascenseurs (`pathway_mode=5`).
`stair_count`	Nombre entier non nul	Optionnelle	Nombre de marches du sentier. Un positif `stair_count` implique que le coureur monte de `from_stop_id` à `to_stop_id`. Et un négatif `stair_count` implique que le coureur descend de `from_stop_id` à `to_stop_id`. Ce champ est recommandé pour les escaliers (`pathway_mode=2`). Si seule une estimation du nombre d'escaliers peut être fournie, il est recommandé d'estimer à 15 le nombre d'escaliers pour un étage.
`max_slope`	Float	Optionnelle	Rapport de pente maximum du cheminement. Les options valides sont `0` ou vide - Pas de pente. `Float` - Rapport de pente du sentier, positif pour le haut, négatif pour le bas. Ce champ ne devrait être utilisé qu'avec les passerelles (`pathway_mode=1`) et les trottoirs roulants (`pathway_mode=3`). Exemple : Aux États-Unis, 0,083 (également écrit 8,3 %) est le taux de pente maximum pour les fauteuils roulants à propulsion manuelle, ce qui signifie une augmentation de 0,083 m (donc 8,3 cm) pour chaque 1 m.
`min_width`	Flotteur positif	Optionnelle	Largeur minimale du sentier en mètres. Ce champ est recommandé si la largeur minimale est inférieure à 1 mètre.
`signposted_as`	Texte	Optionnelle	Texte destiné au public provenant de la signalisation physique et visible par les usagers. Peut être utilisé pour fournir des indications textuelles aux usagers, telles que "suivez les panneaux jusqu'à". Le texte en `singposted_as` devrait apparaître exactement comme il est imprimé sur les panneaux. Lorsque la signalisation physique est multilingue, ce champ peut être renseigné et traduit en suivant l'exemple suivant `stops.stop_name` dans la définition du champ de `feed_info.feed_lang`.
`reversed_signposted_as`	Texte	Optionnelle	Identique à `signposted_as`mais lorsque le chemin d'accès est utilisé à partir de la `to_stop_id` au `from_stop_id`.

levels.txt¶

Fichier : Obligation conditionnelle

Clé primaire (level_id)

Décrit les niveaux dans une station. Utile en conjonction avec pathways.txt, et est obligatoire pour naviguer dans les sentiers avec ascenseurs(pathway_mode=5).

Nom du champ	Type	Présence	Description
`level_id`	Unique ID	Obligatoire	Identifie un niveau dans une station.
`level_index`	Flottant	Obligatoire	Indice numérique du niveau qui indique sa position relative. Le niveau du sol devrait avoir l'indice `0`, les niveaux au-dessus du sol étant indiqués par des indices positifs et les niveaux au-dessous du sol par des indices négatifs.
`level_name`	Texte	Optionnelle	Nom du niveau tel qu'il est vu par le conducteur à l'intérieur du bâtiment ou de la station. Exemple : Prendre l'ascenseur jusqu'à "Mezzanine" ou "Plate-forme" ou "-1".

translations.txt¶

Fichier : Optionnelle

Clé primaire (table_name, field_name, language, record_id, record_sub_id, field_value)

Dans les régions où il existe plusieurs langues officielles, les agences/opérateurs de transport en commun ont généralement des noms et des pages Web language. Afin de mieux servir les usagers de ces régions, il est utile que l'ensemble de données comprenne ces valeurs language.

Nom du champ	Type	Présence	Description
`table_name`	Enum	Obligatoire	Définit la table qui contient le champ à traduire. Les valeurs autorisées sont : - `agency` - `stops` - `routes` - `trips` - `stop_times` - `pathways` - `levels` - `feed_info` - `attributions` Tout fichier ajouté à GTFS aura une `table_name` valeur équivalente au nom du fichier, comme indiqué ci-dessus (c'est-à-dire sans l'extension de fichier). `.txt` l'extension du fichier).
`field_name`	Texte	Obligatoire	Nom du champ à traduire. Les champs de type `Text` peuvent être traduits, les champs de type `URL`, `Email` et `Phone number` peuvent également être "traduits" pour fournir des ressources dans la bonne language. Les champs avec d'autres types ne devraient pas être traduits.
`language`	Code de langue	Obligatoire	Lalanguage de la traduction. Si la language est la même que dans `feed_info.feed_lang`la valeur d'origine du champ sera considérée comme la valeur par défaut à utiliser dans les langues sans traduction spécifique (si le paramètre `default_lang` ne précise pas le contraire). Exemple : En Suisse, une ville située dans un canton officiellement bilingue s'appelle officiellement "Biel/Bienne", mais serait simplement appelée "Bienne" en français et "Biel" en allemand.
`translation`	Texte ou URL ou Email ou Numéro de téléphone	Obligatoire	Valeur traduite.
`record_id`	Foreign ID	Obligatoire sous condition	Définit l'enregistrement qui correspond au champ à traduire. La valeur en `record_id` doit être le premier ou le seul champ de la clé primaire d'une table, comme défini dans l'attribut de clé primaire pour chaque table et ci-dessous : - `agency_id` pour `agency.txt` - `stop_id` pour `stops.txt`; - `route_id` pour `routes.txt`; - `trip_id` pour `trips.txt`; - `trip_id` pour `stop_times.txt`; - `pathway_id` pour `pathways.txt`; - `level_id` pour `levels.txt`; - `attribution_id` pour `attribution.txt`. Les champs des tables non définies ci-dessus ne devraient pas être traduits. Cependant, les producteurs ajoutent parfois des champs supplémentaires qui sont en dehors de la spécification officielle et ces champs non officiels peuvent être traduits. Voici la façon recommandée d'utiliser `record_id` pour ces tables : - `service_id` pour `calendar.txt`; - `service_id` pour `calendar_dates.txt`; - `fare_id` pour `fare_attributes.txt`; - `fare_id` pour `fare_rules.txt`; - `shape_id` pour `shapes.txt`; - `trip_id` pour `frequencies.txt`; - `from_stop_id` pour `transfers.txt`. Conditionnellement obligatoire : - Interdit si `table_name` est `feed_info`. - Interdit si `field_value` est défini. - Obligatoire si `field_value` est vide.
`record_sub_id`	ID étranger	Obligatoire sous condition	Aide l'enregistrement qui contient le champ à traduire lorsque la table n'a pas d'ID unique. Par conséquent, la valeur dans `record_sub_id` est l'ID secondaire de la table, tel que défini par le tableau ci-dessous : - Aucun pour `agency.txt`; - Aucun pour `stops.txt`; - Aucun pour `routes.txt`; - Aucun pour `trips.txt`; - `stop_sequence` pour `stop_times.txt`; - Aucun pour `pathways.txt`; - Aucun pour `levels.txt`; - Aucun pour `attributions.txt`. Les champs des tables non définies ci-dessus ne devraient pas être traduits. Cependant, les producteurs ajoutent parfois des champs supplémentaires qui sont en dehors des spécifications officielles et ces champs non officiels peuvent être traduits. Voici la façon recommandée d'utiliser `record_sub_id` pour ces tables : - Aucun pour `calendar.txt`; - `date` pour `calendar_dates.txt`; - Aucun pour `fare_attributes.txt`; - `route_id` pour `fare_rules.txt`; - Aucun pour `shapes.txt`; - `start_time` pour `frequencies.txt`; - `to_stop_id` pour `transfers.txt`. Conditionnellement obligatoire : - Interdit si `table_name` est `feed_info`. - Interdit si `field_value` est défini. - Obligatoire si `table_name=stop_times` et `record_id` est défini.
`field_value`	Texte ou URL ou Email ou Numéro de téléphone	Conditionnellement obligatoire	Au lieu de définir quel enregistrement devrait être traduit en utilisant `record_id` et `record_sub_id` ce champ peut être utilisé pour définir la valeur qui devrait être traduite. Lorsqu'il est utilisé, la traduction sera appliquée lorsque le champ identifié par `table_name` et `field_name` contient exactement la même valeur que celle définie dans field_value. Le champ ne doit pas avoir exactement la valeur définie dans `field_value`. Si seul un sous-ensemble de la valeur correspond à `field_value`la traduction ne sera pas appliquée. Si deux règles de traduction correspondent au même enregistrement (l'une avec `field_value` et l'autre avec `record_id`), la règle avec `record_id` a la priorité. Conditionnellement Obligatoire : - Interdit si `table_name` est `feed_info`. - Interdit si `record_id` est défini. - Obligatoire si `record_id` est vide.

feed_info.txt¶

Fichier : Optionnelle (Obligatoire si translations.txt est fourni)

Clé primaire (none)

Ce fichier contient des informations sur l'ensemble de données lui-même, plutôt que sur les services que l'ensemble de données décrit. Dans certains cas, l'éditeur de l'ensemble de données est une entité différente de l'une des agences.

Si les deux méthodes de référencementrecord_id, record_sub_id) et field_value sont utilisées pour traduire la même valeur dans 2 lignes différentes, la traduction fournie avecrecord_id, record_sub_id) est prioritaire.

Nom du champ	Type	Présence	Description
`feed_publisher_name`	Texte	Obligatoire	Nom complet de l'organisation qui publie l'ensemble de données. Il peut être identique à l'une des `agency.agency_name` valeurs.
`feed_publisher_url`	URL	Obligatoire	URL du site Web de l'organisation qui publie l'ensemble de données. Il peut être identique à l'une des URL suivantes `agency.agency_url` valeurs.
`feed_lang`	Code de langue	Obligatoire	language par défaut utilisée pour le texte de ce jeu de données. Ce paramètre aide les consommateurs GTFS à choisir les règles de capitalisation et d'autres paramètres language pour le jeu de données. Le fichier `translations.txt` peut être utilisé si le texte doit être traduit dans d'autres langues que celle par défaut. La language par défaut peut être multilingue pour les jeux de données dont le texte original est en plusieurs langues. Dans ce cas, le champ `feed_lang` devrait contenir le code de langue `mul` défini par la norme ISO 639-2, et une traduction pour chaque language utilisée dans l'ensemble de données devrait être fournie dans le fichier `translations.txt`. Si tout le texte original de l'ensemble de données est dans la même language, alors `mul` ne devrait pas être utilisé. Exemple : Considérons un jeu de données provenant d'un pays multilingue comme la Suisse, avec le champ original `stops.stop_name` est rempli de noms d'arrêts dans différentes langues. Chaque nom d'arrêt est écrit en fonction de la language dominante dans l'emplacement géographique de cet arrêt, par exemple `Genève` pour la ville francophone de Genève, `Zürich` pour la ville germanophone de Zurich, et `Biel/Bienne` pour la ville bilingue de Biel/Bienne. L'ensemble des données `feed_lang` devrait être `mul` et les traductions seront fournies en `translations.txt`en allemand `Genf`, `Zürich` et `Biel`; en français : `Genève`, `Zurich` et `Bienne`; en italien : `Ginevra`, `Zurigo` et `Bienna`; et en anglais : `Geneva`, `Zurich` et `Biel/Bienne`.
`default_lang`	Code de langue	Optionnelle	Définit la language qui devrait être utilisée lorsque le consommateur de données ne connaît pas la language de l'avenant. Il s'agira souvent de `en` (anglais).
`feed_start_date`	Date	Optionnelle	L'ensemble de données fournit des informations complètes et fiables sur les horaires du service pour la période allant du début de la journée à la fin de la journée. `feed_start_date` journée à la fin de la `feed_end_date` de la journée. Les deux jours peuvent être laissés vides s'ils ne sont pas disponibles. Le site `feed_end_date` date ne doit pas précéder la `feed_start_date` si les deux sont indiqués. Il est recommandé aux fournisseurs d'ensembles de données de fournir des données d'horaires en dehors de cette période afin d'informer des services futurs probables, mais les consommateurs d'ensembles de données devraient les traiter en tenant compte de leur statut non officiel. Si `feed_start_date` ou `feed_end_date` s'étendent au-delà des dates du calendrier actif définies dans calendar.txt et calendar_dates.txtl'ensemble de données affirme explicitement qu'il n'y a pas de service pour les dates comprises dans la plage `feed_start_date` ou `feed_end_date` mais non incluses dans les dates du calendrier actif.
`feed_end_date`	Date	Optionnelle	(voir ci-dessus)
`feed_version`	Texte	Optionnelle	Chaîne qui indique la version actuelle de leur jeu de données GTFS. Les applications GTFS peuvent afficher cette valeur pour aider les éditeurs de jeux de données à déterminer si le dernier jeu de données a été intégré.
`feed_contact_email`	Courriel	Optionnelle	Adresse e-mail pour la communication concernant le jeu de données GTFS et les pratiques de publication des données. `feed_contact_email` est un contact technique pour les applications GTFS. Fournir les coordonnées du service client par agency.txt.
`feed_contact_url`	URL	Optionnelle	URL pour les informations de contact, un formulaire web, un bureau d'assistance ou d'autres outils de communication concernant le jeu de données GTFS et les pratiques de publication des données. `feed_contact_url` est un contact technique pour les applications consommatrices GTFS. Fournir les informations de contact du service clientèle par agency.txt.

attributions.txt¶

Fichier : Optionnelle

Clé primaire (attribution_id)

Le fichier définit les attributions appliquées au jeu de données.

Nom du champ	Type	Présence	Description
`attribution_id`	ID unique	Optionnelle	Identifie une attribution pour le jeu de données ou un sous-ensemble de celui-ci. Ceci est surtout utile pour les traductions.
`agency_id`	Référencement d'identifiants étrangers `agency.agency_id`	Optionnelle	Agence à laquelle l'attribution s'applique. Si une `agency_id`, `route_id`ou `trip_id` attribution est définie, les autres doivent être vides. Si aucune d'entre elles n'est spécifiée, l'attribution s'appliquera à l'ensemble des données.
`route_id`	Référencement d'identifiants étrangers `routes.route_id`	Optionnelle	Fonctions de la même manière que `agency_id` sauf si l'attribution s'applique à un itinéraire. Plusieurs attributions peuvent s'appliquer à la même route.
`trip_id`	Référencement d'identifiants étrangers `trips.trip_id`	Optionnelle	Fonctions de la même manière que `agency_id` sauf que l'attribution s'applique à un voyage. Plusieurs attributions peuvent s'appliquer au même voyage.
`organization_name`	Texte	Obligatoire	Nom de l'organisation à laquelle le jeu de données est attribué.
`is_producer`	Enum	Optionnelle	Le rôle de l'organisation est producteur. Les options valides sont : `0` ou vide - L'organisation n'a pas ce rôle. `1` - L'organisation a ce rôle. Au moins un des champs `is_producer`, `is_operator`ou `is_authority` devrait être défini à `1`.
`is_operator`	Enum	Optionnelle	Fonctions de la même manière que `is_producer` sauf si le rôle de l'organisation est opérateur.
`is_authority`	Enum	Optionnelle	Fonctions de la même manière que `is_producer` sauf si l'organisation a le rôle d'autorité.
`attribution_url`	URL	Optionnelle	URL de l'organisation.
`attribution_email`	Courriel	Optionnelle	Email de l'organisation.
`attribution_phone`	Numéro de téléphone	Optionnelle	Numéro de téléphone de l'organisation.