Mise en qualité des données GTFS
ou comment publier en open data des données de qualité afin de faciliter leur intégration dans des applications tierces et ainsi encourager les usagers à emprunter les transports en commun ?
Pour mettre en valeur votre réseau de transport à travers les supports numériques, il est important que vos GTFS comportent un maximum d'information à caractère commercial (nom commerciaux des lignes et arrêts, couleurs des lignes, accessibilité des arrêts, tracés des itinéraires, coordonnées de l'agence commerciale etc.).
La présence de ces informations assure la cohérence de votre réseau par rapport à votre stratégie commerciale et de communication et est complémentaire de vos autres supports (fiches horaires dépliants, affichage aux arrêts, plans de réseaux et de lignes etc.).
En renseignant ces informations, vous facilitez la réutilisation de données tout en restant maitre de la diffusion des éléments constitutifs de votre réseau. Vous permettez ainsi, à travers l'intégration de vos données dans des calculateurs d'itinéraires, de toucher une plus grande cible de voyageurs potentiels en leur offrant une information de qualité représentative de votre réseau.
En effet, un GTFS ne sert pas uniquement à décrire vos horaires, il permet également de décrire au mieux votre réseau, ses lignes et ses arrêts notamment, à travers des champs spécifiques que nous allons voir dans la suite de ce document.
A travers les champs
route_text_color et route_color du fichier routes.txt, vous pouvez renseigner les couleurs de vos lignes afin qu'elles apparaissent telles quelles dans les calculateurs d'itinéraires ou dans tout autre canal qui publierait des informations sur vos lignes. Ainsi, l'information est cohérente entre tous les supports : vos supports distribués sur le réseau et les supports numériques. Les codes couleurs sont à renseigner au format hexadécimal. Différents outils gratuits existent sur internet pour convertir simplement vos codes couleurs RGB en hexadécimal.
Exemple : #FFFFFF = blanc, #000000 = noir
Il existe deux champs disponibles dans le fichier
routes.txt du GTFS pour décrire les noms des lignes : - le champ
route_short_name ou “nom court” - et le champ
route_long_name ou “nom long”. Il est obligatoire d’en renseigner a minima l’un des 2, mais nous vous préconisons de renseigner les 2.
En effet, ces 2 champs n’ont pas la même vocation :
- Le nom court va être utilisé lors de recherches d’itinéraires pour afficher les options possibles. Généralement il s’agit d’une lettre ou d’un chiffre.
Exemple “A” ou “1” ou encore “212”.
- Le nom long en revanche, a vocation à être utilisé lorsque la liste des lignes apparaît, en vue d’obtenir sa fiche horaire par exemple. Il est donc important que ce nom soit le plus descriptif possible afin que les voyageurs s’y retrouvent facilement. Généralement, ce nom est le même que celui qui se trouve sur vos dépliants horaires distribués. Il se compose souvent de l’origine et de la destination de la ligne.
Exemples (réseau Bibus de Brest Métropole) :
- “Gare - Hôpital Cavale” pour les lignes couvrant une seule collectivité
- “PLOUZANE Bourg - BREST Hôpital Cavale” lorsque le périmètre de la ligne couvre plusieurs collectivités, on peut ajouter le nom des villes en questions pour donner un maximum de précisions au voyageur.
Illustration de l’utilisation des noms longs (1ère image) et courts (2ème et 3ème image) des lignes dans une application mobile (Source : Bibus de Brest Métropole)
Dans la mesure du possible, nous préconisons d'intégrer au fichier GTFS le fichier
shapes.txt permettant de décrire le tracés des itinéraires de vos lignes. Ainsi, lors des réutilisations de votre fichier, les itinéraires proposés indiqueront les routes réellement empruntées et non pas des itinéraires calculés par le calculateur ou des itinéraires "à la volée" non représentatifs de la réalité. Attention, pour pouvoir être utilisé, il faut bien que les
shape.id soient repris dans le fichier trips.txt.Le fichier
agency.txt permet de renseigner les informations relatives à votre agence commerciale à savoir : - l'url du site web si vous disposez d'un site dédié à votre réseau de transport (
agency_url) - le nom commercial de votre réseau de transport (
agency_name) - le numéro de téléphone dédié à la relation clients (
agency_phone)Ces informations sont ensuite reprises dans les différents calculateurs d'itinéraires afin d'être présentées aux usagers dans le cas où ils auraient besoin de plus d'informations.
Il est possible de créer plusieurs agences dans votre GTFS. Ainsi, si vous avez des lignes régulières et des lignes TAD vous pouvez tout à fait créer deux agences distinctes et ainsi inscrire les 2 coordonnées différentes (site internet du réseau de bus et site internet de réservation du TAD par exemple, idem pour le numéro de téléphone). L'information voyageurs sera alors d'autant plus précise.
Le fichier
stops.txt permet de décrire les arrêts : nom commercial, ID, coordonnées etc. Il permet également de décrire si l'arrêt est aménagé pour les usagers en fauteuil roulant grâce au champ wheelchair_boarding. 3 caractéristiques sont possibles :
-
0 ou vide : information non connue / non renseignée
- 1 : certains véhicules à cet arrêt peuvent accueillir un usager en fauteuil roulant.
- 2 : les usagers en fauteuil roulant ne peuvent pas monter à bord des véhicules à cet arrêt.NB : attention, un arrêt peut être décrit comme étant accessible dans le GTFS, mais le véhicule qui dessert cet arrêt doit également être en mesure d'accueillir un usager en fauteuil roulant. Cette information peut être retrouvée dans le champ
wheelchair_accessible du fichier trips.txt (cf. paragraphe suivant sur l'accessibilité du trajet)Le champ
wheelchair_accessible du fichier trips.txt permet de décrire si le véhicule utilisé sur le trajet (trip) autorise ou non les usagers en fauteuil roulant.Les caractéristiques possibles sont :
0 ou vide : aucune information disponible concernant les aménagements pour usagers en fauteuil roulant pour le trajet.
1 : le véhicule utilisé pour ce trajet peut accueillir au moins un usager en fauteuil roulant.
2 : le véhicule utilisé pour ce trajet ne peut accueillir aucun usager en fauteuil roulant.C'est en croisant les informations aux arrêts et dans les véhicules que le calculateur d'itinéraire peut proposer des itinéraires accessibles aux usagers en fauteuil roulant. Nous encourageons donc vivement les producteurs de données à renseigner ces 2 champs pour fournir une information la plus juste possible aux usagers.
Le champ
bikes_allowed du fichier trips.txt permet de décrire si le véhicule utilisé sur le trajet (trip) autorise ou non le transport d'un vélo non démonté avec soi.Les caractéristiques possibles sont :
0 ou vide : aucune information disponible concernant les aménagements pour vélos pour le trajet.
1 : le véhicule utilisé pour ce trajet peut accueillir au moins un vélo.
2 : le véhicule utilisé pour ce trajet ne peut accueillir aucun vélo.Les champs
pickup_type (montée à bord) et drop_off_type (descente du véhicule) du fichier stop_times.txt permet de décrire si le passage du véhicule est à la demande ou non (autrement dit, s'il est nécessaire de réserver son trajet ou non).Les caractéristiques possibles sont :
0 ou vide : les usagers peuvent monter / descendre aux horaires standards.
1 : les usagers ne peuvent pas monter / descendre du véhicule
2 : les usagers doivent téléphoner à l'agence pour pouvoir monter / descendre du véhicule
3 : les usagers doivent contacter le conducteur pour pouvoir monter / descendre du véhiculeEn cas de réservation, les calculateurs reprendront le numéro de téléphone contenu dans le fichier
agency.txt. Dans le cas où votre réseau dispose de lignes 100% TAD nous vous suggérons de les associer à une agence spécifique TAD afin de faire apparaitre directement le numéro de réservation et non le numéro générique de votre agence (voir ci-dessus le chapitre agence).NB : ce sont également ces champs qui permettent de modéliser les ITL (Interdiction de Trafic Local) via une caractérisation du passage en "
1".- Plus de thématiques à venir (tarification...)
- Pour plus d'informations, vous pouvez également lire les best practices référencées par Mobility Data.
Dernière mise à jour 4mo ago