FR:General Transit Feed Specification
Le GTFS (spécification générale pour les flux relatifs aux transports en commun) est un format de données créé pour partager des informations sur les transports publics telles que les arrêts de bus, les itinéraires et les horaires de bus.
Il est utile pour les utilisateurs potentiels des données OSM de fournir des itinéraires (route) utilisant les transports publics car, dans de nombreux cas, les horaires changent si souvent qu'il est de facto impossible de les représenter dans OSM. Dans certaines villes, on peut s'attendre à ce que les horaires changent tous les jours en raison de la fermeture ou de la rénovation de routes ou de voies ferrées. Et dans certaines régions, les horaires sont modifiés massivement plusieurs fois au cours de l'année, par exemple lors des vacances et des rentrées et sorties d'école.
Dans de tels cas, les consommateurs de données peuvent utiliser les données OSM pour les routes, les positions des arrêts et les voies piétonnes et prendre les trajets (trip) disponibles sur les transports publics directement auprès de l'organisme de transport.
Cette spécification s'appelait à l'origine Google Transit Feed Specification, et a été développée par Google. Elle est désormais gérée par l'organisation MobilityData qui gère également des outils permettant d'utiliser les données GTFS, une base de données des données GTFS et la spécification générale des flux de vélos en libre-service General Bikeshare Feed Specification.
Structure du GTFS
Un flux GTFS GTFS feed est une URL (stable) qui publie un fichier ZIP contenant plusieurs fichiers CSV.
Il est souvent mis à jour régulièrement, auquel cas un fichier zip particulier est désigné comme une version du flux GTFS.
Le fichier stops.txt contient des informations sur les lieux physiques.
stop_id
- l'identifiant de cet emplacement,stop_code
,stop_name
- l'identifiant et le nom de l'emplacement pour le public,stop_lat
,stop_lon
- coordonnées GPS, pour les arrêts sur le poteau,platform_code
- l'identifiant d'une plate-forme (platform) spécifique.
Bien que le fichier s'appelle stops.txt, il contient également des informations sur les gares, les entrées et les zones d'embarquement. Celles-ci sont distinguées à l'aide de location_type
, et liées à une structure plus large à l'aide de parent_station
location_type
|
Description | Parent | Description GTFS | concept PTv2 |
---|---|---|---|---|
0 | stop GTFS | station | Lieu d'embarquement/débarquement des passagers | public_transport=platform (préféré)
public_transport=stop_position |
1 | station GTFS | - | Structure physique ou zone (area) avec une ou plusieurs plates-formes (platforms) | public_transport=station public_transport=stop_area public_transport=stop_area_group |
2 | entrée/sortie | station | Emplacement où les passagers entrent/sortissent d'une station | railway=subway_entrance railway=train_station_entrance |
3 | nœud générique | station | Emplacement dans une station, utilisé pour définir les cheminements | |
4 | zone d'embarquement | platform | emplacement sur un quai (platform) |
Le fichier routes.txt contient la description d'une route.
Une route GTFS correspond à une type=route_master
route_id
- l'identifiant de cet itinéraire (route),agency_id
- l'identifiant de l'agence qui gère l'itinéraire (route), qui peut être consulté dans le fichier agency.txt,route_short_name
- l'identifiant court de l'itinéraire, comme un numéro de bus,route_long_name
- le nom complet de l'itinéraire, souvent avec les destinations,route_type
- le type de transport public utilisé ; bus/train/metro/...
Le fichier trips.txt contient des descriptions de trajets (trip) - une séquence d'arrêts visités à un moment donné.
La séquence réelle des arrêts se trouve dans stop_times.txt, qui fait référence à trip_id
.
Un GTFS trip (trajet GTFS) correspond grosso modo à une type=route, à l'exception de l'inclusion d'informations temporelles..
trip_id
- l'identifiant de ce trajet,route_id
- l'itinéraire (route) auquel les trajets appartiennent,service_id
- les jours de fonctionnement (calendar.txt),trip_headsign
- la destination affichée du trajet,trip_short_name
- le texte public permettant d'identifier le trajet (trip),direction_id
- la direction du trajet, qu'il s'agisse d'un trajet entrant ou sortant / dans le sens des aiguilles d'une montre ou dans le sens inverse des aiguilles d'une montre / ...shape_id
- si présent, la forme du trajet entre les arrêts (shapes.txt).
Le fichier stop_times.txt décrit l'heure à laquelle un trajet s'arrête à un arrêt.
Un GTFS Stop time heure d'arrêt GTFS est défini par la combinaison d'un trip_id
et d'une stop_sequence.
Il contient l'identifiant stop_id
de l'arrêt visité, ainsi que l'heure d'arrivée arrival_time
et l'heure de départ departure_time
.
En outre, il peut contenir des informations sur la possibilité d'embarquer ou de débarquer à cet arrêt ou le long de l'itinéraire jusqu'à l'arrêt suivant.
Le fichier shapes.txt contient les chemins parcourus par les véhicules, comme un itinéraire GPX.
Une forme GTFS shape correspond à peu près à une type=route, à l'exception de l'exclusion de la séquence des arrêts.
Les formes sont souvent référencées par plusieurs trajets qui suivent le même chemin.
Attributs
Règles générales
Il existe actuellement deux espaces de noms (gtfs_*
et gtfs:*
) utilisés pour les attributs liées au GTFS.
Dans Proposal:GTFS Tagging Standard il a été décidé d'utiliser l'espace de noms gtfs:*
.
Par conséquent, l'utilisation d'attributs dans l'espace de noms gtfs_*
est déconseillée.
Toute attribut existant est interprété comme le même attribut dans l'espace de noms gtfs:*
.
Lorsqu'un attribut fait référence à une colonne d'un fichier GTFS, il doit utiliser le nom complet de cette colonne.
Par exemple, utilisez gtfs:route_long_name=* au lieu de gtfs:name=*, et gtfs:stop_id=* au lieu de gtfs:id=*.
Il est ainsi plus facile pour un consommateur de données de trouver le bon fichier et la bonne colonne.
Les attributs permettant d'établir un lien avec un objet GTFS doivent utiliser l'espace de noms gtfs:*
au lieu des attributs standard tels que name=* et ref=*/ref:IFOPT=*.
Pour trouver l'objet GTFS correspondant, il faut une correspondance exacte avec la valeur du flux.
Cela diffère des exigences des attributs standards, qui s'adressent aux humains.
L'utilisation d'attributs standards pour la correspondance signifie que le lien est interrompu lorsque les majuscules sont modifiées, que des abréviations sont ajoutées/supprimées, ... .
Il est préférable d'utiliser à la fois les attributs standards et les attributs GTFS, même si ce sont exactement les mêmes.
Lien vers un objet GTFS
Pour consulter les horaires d'un arrêt ou d'une ligne (route) en particulier, nous voulons un moyen de trouver l'objet GTFS correspondant.
Pour ce faire, suivez les étapes suivantes :
Étape 1 : Analyse du flux (feed)
Différentes versions du flux peuvent avoir des identifiants différents pour le même objet.
Pour s'assurer que le lien vers l'objet n'est pas rompu pour une nouvelle version du flux, examinez les versions historiques.
Déterminez quelles colonnes ont une valeur stable et lesquelles n'en ont pas.
L'utilisation d'une valeur en dehors du flux GTFS indique également qu'il est peu probable que cette valeur change.
Étape 2 : Documenter le flux
Consultez la liste des flux (feed) GTFS List of GTFS feeds.
Si le flux auquel l'objet appartient n'y figure pas, ajoutez une nouvelle entrée en utilisant le modèle de flux GTFS GTFS feed template.
Le code du flux peut être quelconque, mais nous vous encourageons à respecter les deux règles suivantes :
- Commencez le code du flux par le code de région ISO 3166-2 pour la région dans laquelle le service opère.
- Ne pas inclure de deux-points (
:
) dans le code du flux, car ils sont utilisés comme séparateurs dans les clés.
Mémorisez le code de flux pour le flux.
Étape 3 : Référencement de l'objet
Trouvez une combinaison des attributs suivants pour référencer un objet GTFS :
Type | Attributs |
---|---|
stop | gtfs:stop_id:*=*, gtfs:stop_code:*=*, gtfs:stop_name:*=*, gtfs:location_type:*=0, gtfs:platform_code:*=* |
station | gtfs:stop_id:*=*, gtfs:stop_code:*=*, gtfs:stop_name:*=*, gtfs:location_type:*=1 |
entrance (entrée) | gtfs:stop_id:*=*, gtfs:stop_code:*=*, gtfs:stop_name:*=*, gtfs:location_type:*=2 |
route | gtfs:trip_id:*=*, gtfs:trip_id:sample:*=*, gtfs:shape_id:*=* |
route master | gtfs:route_id:*=*, gtfs:route_long_name:*=*, gtfs:route_short_name:*=* |
La combinaison d'attributs doit correspondre exactement à un objet dans le flux.
En outre, essayez d'éviter de mettre des attributs sur les colonnes que vous avez trouvées instables.
Remarque : il est également possible de placer des attributs sur d'autres colonnes, mais elles ne sont pas prises en compte pour la mise en correspondance.
Envisagez de les placer dans des attributs standards afin qu'ils puissent être lus par des applications qui ne traitent pas les attributs GTFS.
Exemple : colour=#008080 au lieu de (ou en plus de) gtfs:route_color:*=#008080.
Valeur par défaut pour location_type
Nous avons parfois besoin de location_type
pour distinguer les plates-formes (platform) des stations.
Au lieu de mettre un attribut directement, il est possible de le déduire à partir du type d'objet PTv2 à l'aide du tableau de la section "Structure du GTFS" (Structure of GTFS).
En raison de ces valeurs par défaut, le location_type
est toujours utilisé pour la mise en correspondance des lieux.
Dans les rares cas où aucune valeur ne peut être déduite (pas ou plusieurs correspondances), gtfs:location_type:*=* doit être ajouté.
Interprétation de gtfs:id:*=* déconseillé
L'utilisation de gtfs:id:*=* est déconseillée car il n'est pas clair à quelle table du flux GTFS elle fait référence.
Utilisez plutôt gtfs:stop_id:*=*, gtfs:trip_id:*=*, gtfs:trip_id:sample:*=*, gtfs:shape_id:*=* ou gtfs:route_id:*=*.
Toutefois, si l'attribut est présent, il doit être interprété comme suit :
- Si l'un des attributs énumérés dans le tableau de la section "Structure du GTFS" est présent, il a la même signification que gtfs:stop_id=*.
- S'il est associé à une type=route, il a la même signification que gtfs:trip_id:*=*.
- S'il est associé à une type=route_master, il a la même signification que gtfs:route_id:*=*.
Interprétation de gtfs:name=*, gtfs:short_name:*=* et gtfs:long_name:*=* déconseillés
L'utilisation de gtfs:name:*=* est déconseillée car il n'est pas clair à quelle table du flux GTFS elle fait référence.
Utilisez plutôt gtfs:stop_name:*=*, gtfs:route_short_name:*=*, gtfs:route_long_name:*=*, gtfs:trip_short_name:*=*. Toutefois, si l'attribut est présent, il doit être interprété comme suit :
- Si un des attributs énumérés dans le tableau de la section "Structure du GTFS" est présent, il a la même signification que gtfs:stop_name:*=*.
- S'il a été marqué comme une type=route, il a la même signification que gtfs:trip_short_name:*=*.
- S'il a été marqué comme une type=route_master, il a la même signification que gtfs:route_short_name:*=*.
Step 4: Regrouper les attributs avec le code du flux
Ajouter le code du flux en suffixe des clés.
Cela garantit qu'un consommateur de données peut trouver le flux et qu'il sait quelles colonnes il doit consulter pour trouver la bonne colonne.
L'utilisation du code comme suffixe permet également de référencer des objets dans plusieurs flux, par exemple pour les stations situées près des frontières.
Interprétation de gtfs:feed=*
déconseillé
L'utilisation de gtfs:feed=* est déconseillée, Utilisez plutôt les suffixes des codes de flux.
Toutefois, si l'attribut est présent, il doit être interprété comme si sa valeur avait été ajoutée en tant que suffixe du code du flux à toutes les clés GTFS qui ne disposent pas déjà d'un tel suffixe.
Ainsi, la combinaison gtfs:feed=NL-OVApi + gtfs:stop_code=nm est interprétée comme gtfs:stop_code:NL-OVApi=nm
Aperçu des attributs utilisés
Clés avec des pages wiki
- gtfs:feed=* - déconseillé - décrit le flux auquel l'objet appartient,
- gtfs:name=* - déconseillé - nom de l'objet conformément au flux GTFS,
- gtfs:release date=* - version du flux utilisée pour le "date",
- gtfs:route id=* - identifiant permettant d'associer les relations type=route_master aux itinéraires (route),
- gtfs:shape id=* - identifiant privilégié d'une variante d'itinéraire (route) -- pas toujours présent, ne fournit pas d'informations sur les positions des arrêts,
- gtfs:stop id=* - identifiant permettant d'associer les arrêts à leur équivalent GTFS,
- gtfs:trip id=* - alternative pour les variantes d'itinéraires (route) ne comportant qu'un seul trajet (trip),
- gtfs:trip id:sample=* - solution de rechange pour identifier une variante d'itinéraire (route) -- mais plus susceptible de changer, fournit des informations sur les positions des arrêts et leur séquence uniquement,
- gtfs id=* - déconseillé - identifiant de l'objet dans un flux GTFS.
Clés par utilisation (plus de 100 utilisations au moment de la mise à jour)
Attributs actuellement inutilisés mentionnés précédemment sur cette page
Alternative pour les arrêts
En Europe, pour les arrêts de transport public, la norme européenne IFOPT (en) est définie et dans certaines données GTFS, le code d'arrêt stop_code
est identique aux références IFOPT. Dans ces situations, il est recommandé de mettre en place à la fois les attributs gtfs:stop_code:*=* et ref:IFOPT:[[Key:|]]=*.
ref:IFOPT:[[Key:|]]=*
Sources des données
- PTNA - Public Transport Network Analysis (analyse du réseau de transport public) regroupe des données GTFS ouvertes et sous licence correcte provenant de quelques pays. D'autres pays peuvent facilement être pris en charge sur demande et des liens vers les sources sont fournis.
- GTFS Data Exchange (Échange de données GTFS) - Données disponibles pour 1000 agences de transport en commun (au 9 décembre 2016), mais les licences varient. Actuellement fermé.
- Mobility Database (Mobility Database (anciennement TransitFeeds/OpenMobilityData) - projet d'agrégation de données GTFS en open source.
- Transitland at transit.land - agrégation des données GTFS financée par des fonds commerciaux.
- transport.data.gouv.fr - données ouvertes GTFS françaises (ODbL).
- NAPs de l'Union européenne - liens vers des fichiers `.pdf` contenant les points d'accès nationaux de l'UE (voir aussi liste non officielle).
Visualisation de GTFS
- PTNA - belle visualisation en ligne des données GTFS agrégées et correctement exploitées sous licence avec des recommandations d'attributs pour les relations d'itinéraires (route) et une superposition de cartes pour les formes (shape).
Conversion d'OpenStreetMap et GTFS
OSM → GTFS
- osm2gtfs - Un script python extensible pour interroger les données OpenStreetMap sur les transports publics, en les combinant avec des informations temporelles fournies par une autre source et en les convertissant au format GTFS.
GTFS → OSM
- GO-Sync (aka gtfs-osm-sync) - Un outil de bureau pour synchroniser les flux GTFS avec OSM.
- GTFS-OSM-Validator - Outil de console qui lira le GTFS et affichera les problèmes exacts qu'il trouve dans OSM.
- gtfs-sql-importer - Cet outil permet de convertir le GTFS en schéma SQL postgis dans lequel le GTFS peut être manipulé. D'autres exemples de cet outil peuvent être trouvés dans GTFS SQL examples.
- GTFS-OSM-Import - Outil open-source pour automatiser et simplifier autant que possible l'importation de données GTFS dans OSM.
- GTFS Janitor - Outil basé sur le web pour combiner les flux GTFS avec les données OSM.
Aide aux éditeurs
- Le préréglage externe de JOSM Public Transport GTFS et la règle Public Transport GTFS prennent en charge certains des attributs.
Logiciels utilisant des attributs
- PTNA évalue gtfs:feed=*, gtfs:release_date=*, gtfs:route_id=*, gtfs:shape_id=*, gtfs:trip_id:sample=* et gtfs:trip_id=* et pour fournir un lien entre la relation et les données GTFS.
- En comparant GTFS et OSM, PTNA évalue aussi gtfs:stop_id=* et
gtfs:stop_id:<feed>
(exemple: Gare Clémenceau à Lannion à partir du 2024-12-22) sur la page de comparaison (à partir du 2024-12-22).
Discussions
- GO-Sync - GO-Sync - un outil de synchronisation des données GTFS et OpenStreetMap (en) - un fil de discussion Google Groups annonçant gtfs-osm-sync, et les difficultés des opérateurs multiples pour les arrêts de bus.
- GO-Sync - un outil de synchronisation des données GTFS et OpenStreetMap (en) - annonce de gtfs-osm-sync sur Talk-transit.
- Compatibilité GTFS (en), ([1] et [2]) - discussion sur Talk-transit.
- Arrêts de bus en Amérique du Nord d'après les données GTFS (en) - fil de discussion sur Talk-transit
- Proposition : Norme d'attributs GTFS (en)