Retour d’expérience avec le GTFS de la STIB

Publié par Jonathan Estevez le

Voilà déjà quelques temps que je travail par plaisir sur l’exploitation des données fournies par l’Open data de la STIB.

L’une des données fournies par cet Open Data est la récupération des fichiers GTFS. Les fichiers GTFS sont un format de fichiers utilisé entre autres par Google afin qu’un opérateur tel que la STIB puisse mettre à disposition ses horaires théoriques sur Google Maps. C’est devenu depuis un format assez rependu pour qu’un opérateur mette à disposition ses horaires avec tous les services qui le souhaitent.

Si le format de fichier est standardisé, les données que l’on y retrouve ont toujours un lien particulier avec l’opérateur de transports publics qui le publie. Dans cet article, je vous partagerai mon expérience dessus ainsi que les éventuels liens avec l’Open API permettant entre autres de retrouver des informations en temps réel.

Les fichiers du GTFS de la STIB

Dans l’archive zip du GTFS de la STIB, on y retrouve 9 fichiers txt

  • agency.txt : ce fichier reprend des informations sur l’opérateur, ici, la STIB. Ce fichier est très peu utile si vous vous concentrez uniquement sur la STIB dans l’exploitation de GTFS.
  • calendar.txt : ce fichier permet de savoir quel horaire sera utilisé et quand.
  • calendar_dates.txt : ce fichier comprendra les exceptions sur les dates. Par exemple, les horaires du vendredi 1e mai ne seront pas le standard mais seront un horaire dimanche par exemple.
  • routes.txt : ce fichier reprendra les lignes dont un horaire sera envoyé.
  • shapes.txt : ce fichier contiendra les données permettant de créer une carte des trajets et donc des lignes et du réseau.
  • stop_times.txt : ce fichier contiendra les horaires aux arrêts avec un grand nombre d’informations supplémentaires.
  • stops.txt : ce fichier contiendra les arrêts.
  • translations.txt : ce fichier contiendra les informations dans chaque langue envoyée. Par exemple les terminus, les arrêts ou les accès d’une station.
  • trips.txt : ce fichier comprendra chaque voyage avec certains liens tels que la ligne, les arrêts et l’ordre.

L’exploitation des données

Quelques petites règles pour commencer: un fichier GTFS sera publié pour une utilisation dans le futur. Très rarement, l’utilisation commencera le jour même (Même jamais de mémoire). Par exemple, un fichier est publié dans la nuit d’un samedi à un dimanche mais son utilisation commencera seulement le lundi qui suit. Sachant qu’alors, le précédent fichier, lui, ne sera plus utilisé dès ce même lundi même si les données du calendrier du précédent fichier pouvaient indiquer le contraire.

La STIB indique ceci pour le fichier GTFS:

Les fichiers GTFS sont zippés dans un fichier d’environ 25 Mb. Ils sont mis à jour toutes les deux semaines.
Afin de rester à jour, il suffira de télécharger ce fichier tous les quatorze jours.

Documentation en PDF sur l’Open Data portal de la STIB

Si cela peut être correcte dans la majorité des cas dans une situation normale, certaines exceptions, et encore plus depuis la crise du Covid-19, font contredire cela. Faute de savoir si une nouvelle version est disponible, vérifier chaque nuit si le fichier a changé (en le téléchargeant et en faisant par exemple un checksum md5) semble être le meilleur moyen de détecter si une nouvelle version est disponible.

La première chose à faire quand on utilise les données GTFS, c’est de travailler avec un système de “version” où la date de début devra être déterminée avec la plus petite date fournie dans le fichier calendar. En même temps, la précédente version devra avoir sa date de fin d’utilisation la veille du jour du nouveau fichier.

Les lignes ou routes

La STIB fournit un fichier de routes. Celui-ci contiendra toutes les lignes exploitées sur la période de validité. Toutefois, on retrouvera plusieurs particularités :

  1. Tous les fichiers GTFS seront basés sur un ID propre au fichier GTFS, à chaque version la ligne 71, par exemple, aura un id différent. Il faudra alors faire son propre système afin de maintenir le lien entre les données de différentes versions basées sur la “vraie” ligne.
  2. Heureusement, le fichier routes.txt contiendra quand même le “numéro” de ligne. On retrouvera ainsi la ligne de bus 71, la ligne de navettes T39 ou la ligne noctis N18. Toutefois, si vous souhaitez faire le lien avec l’API du temps réel, cet ID ne vous sera d’aucune utilisé car si la ligne 71 reste bien la ligne 71, la ligne T39 aura en réalité l’ID 139, ou encore la ligne N18 aura l’ID 218. Pour connaitre cette ID, il vous faudra passer par le fichier trips.txt où le lien entre les routes est fait et récupérer l’ID de la ligne via l’ID du shapes. Cet ID contiendra dans les 3 premiers caractères le vrai ID de ligne. Attention, il faudra le récupérer au format numérique. C’est à dire les 3 premiers caractères seront 071 par exemple, ce qui deviendra alors 71.
  3. Si le fichier routes contient bien les terminus, celui-ci est contenu dans une seule chaine de caractères. Il n’y a malheureusement aucun moyen de récupérer le terminus de ville ou de faubourg de façon sûre. L’une des façons de faire est de couper la chaine de caractères en 2 en utilisant comme argument de découpe ” – ” (Espace Tiret Espace). Sachant que certaines lignes n’ont pas de double terminus, et il faudra dès lors également le gérer, les terminus devront être réellement récupérés via un lien avec le fichier translations.txt

Pour le reste, je vous invite à lire la documentation du GTFS et particulièrement le fichier routes.txt via https://developers.google.com/transit/gtfs/reference#routestxt

Les voyages ou trips

Ce fichier est dans un sens le cœur du fichier GTFS. C’est lui qui fera le lien entre les lignes, les dates, les horaires aux arrêts ainsi que les éléments permettant de créer les cartes.

Le premier champ, route_id, contient le lien vers le fichier routes.txt

Le second champ, service_id, est lui l’ID d’un service. Un service contiendra un certain nombre de voyages sur une ou plusieurs lignes. Ce service sera ensuite le lien avec les dates d’exploitation qui seront dans les fichiers calendar.txt et calendar_dates.txt

Le troisième champ, trip_id, est l’id du voyage.

Le quatrième champ, trip_headsign,, contiendra la destination du véhicule. Il sera utile de rechercher la traduction dans le fichier translations si elle s’y retrouve. Attention, ce terminus n’est pas forcément l’arrêt réel de fin du trajet. Par exemple, si des travaux ont lieu sur une ligne de tram et qu’une navette existe, la destination pourra être l’arrêt normal alors qu’un changement pour une navette est nécessaire. C’est donc plus un champ de label et/ou d’information qu’un champ stricte.

Le cinquième champ contient la direction de circulation. 0 pour faubourg et 1 pour ville.

Le sixième champ, block_id, est intéressant car il contient tous les voyages effectués par un même véhicule. Un véhicule sort du dépôt, effectue des voyages sur une ou plusieurs lignes puis rentre au dépôt. Ce champ permet d’avoir l’information permettant de suivre l’horaire complet.

Le septième champ, shape_id, est l’id des informations cartographiques liées au voyage. A faire le lien avec les données dans le fichier shapes.txt.

Les arrêts ou stops

Le fichier stop.txt va contenir tous les arrêts où un horaire aura été généré de façon théorique. Pour faire simple, on peut avoir 3 types d’arrêts :

  • Les arrêts offrant une desserte régulière. Il s’agit des arrêts prévus sur l’itinéraire normal d’une ligne.
  • Il y a ensuite les arrêts où une déviation a été planifiée avec un horaire de déviations. Par exemple lorsqu’un chantier important est prévu et où un horaire est fait pour la durée du chantier.

Pour les deux premiers cas, on retrouvera les informations dans ce fichier.

  • Le troisième type d’arrêts reprend ceux où une déviation est mise en place sans aucun horaire spécifique. Dans ce cas, des arrêts peuvent être créés mais aucun horaire n’est prévu. L’itinéraire, lui non plus, n’indique pas ces arrêts.
    Le seul moment où on sera confronté à ce type d’arrêt, c’est dans le suivi en temps réel. En effet l’API de la STIB renvoi la position des véhicules et cela peut remonter un véhicule à un arrêt qui n’est pas prévu. Bien sûr, la déviation peut se faire en offrant une desserte d’un arrêt d’une autre ligne, tout comme cela peut se faire à un arrêt spécifiquement créé pour la déviation.

Autre particularité des arrêts, un même arrêt peut avoir 2 numéros. Cela se présente dans 2 cas de figure :

  • Le premier est une zone d’arrêts où les véhicules s’arrêtent pour les 2 directions. Le cas qui me vient à l’esprit est celui des arrêts de la ligne 42 devant l’Hôpital Saint-Luc. Si vous allez sur place, vous ne verrez qu’une seule plaque avec les 2 directions et le panneau en temps réel indiquera aussi les 2 directions. Alors que via le GTFS ou l’Open Data, il y aura une distinction. Dans ce cas de figure, les numéros seront totalement différents.
  • Le second cas de figure, c’est un arrêt où une zone bus et une zone tram existent. Ici, le cas qui me vient à l’esprit est celui de l’arrêt Brésil sur la ligne de bus 41 et les lignes de tram 8 & 25. Dans ce cas de figure, la distinction se fera sur un seul caractère. L’arrêt du tram aura comme référence 5415F alors que l’arrêt de bus aura pour référence 5415. Cela ne serait pas très important si, pour le temps réel, seule la référence sur 4 caractères était connue. Ainsi, que ce soit pour le bus ou le tram, le temps réel sera fourni uniquement via la référence 5415.

Il vous faudra dès lors maintenir un système de double référence si vous souhaitez avoir un lien entre le temps réel et le temps théorique.

Outre le fait de contenir les arrêts à proprement parlé, le fichier contient également des informations sur les stations telles que les stations et les sorties. Les arrêts des stations étant reliés grâce à un ID, il vous faudra y faire attention lors du traitement du fichier.

Les horaires aux arrêts ou stop_times

Le fichier stop_times.txt contient les horaires de passages aux arrêts. Le lien se fait sur base du trip_id. On y retrouve un champ pour l’horaire d’arrivée et l’horaire de départ. Horaire qui est chaque fois le même. On y retrouve la référence à l’arrêt, l’ordre de l’arrêt sur un voyage ainsi que des indications sur la montée et la descente autorisée. Malheureusement, ces indications ne sont pas forcément correctes. Je vous conseille de ne pas trop y faire attention.

Les shapes

Le fichier shapes.txt contient les informations avec les latitudes et longitudes pour chaque point permettant de dessiner le trajet d’un itinéraire.

Une des particularités du fichier est de contenir dans la majorité des cas des ID qui vont par 10000 entre chaque arrêt. Ainsi, si un itinéraire est composé de 10 arrêts. Nous aurons 9 groupes de coordonnées. Allant de 10001 à 100xxx. Il faut vérifier car cela n’est pas le cas dans de rares occasions mais cela permet dès lors de faire la carte en affichant uniquement les parties désirées.

Autre particularité, si un itinéraire commence à un arrêt qui n’est pas sur un itinéraire standard, le dessin de la ligne peut présenter plusieurs lignes. Si les différences sont minimes, cela peut ne pas être très beau au niveau visuel. Un petit travail de fusion pourrait être nécessaire en fonction de l’utilisation que vous en faites.

Pour conclure

Voici ce que je pouvais vous partager de mon expérience sur la partie liée aux GTFS de la STIB. Si certaines choses ne vont probablement jamais changer, d’autres pourraient très bien changer dans le futur. Il faudra dès lors être prudent et avoir assez d’intelligence dans les systèmes de gestion des fichiers pour en tenir compte. Surtout si votre utilisation est différente de celle qui est de simplement afficher les informations sans avoir de réel besoin de liens entre celles-ci.

Catégories : Expérience client

Jonathan Estevez

J’aime les nouvelles technologies, au point d’avoir fait de ma passion mon métier en étant « System Administrator ». Ma vie en Hastag ? #Geek #ICT #Telecom #Mobile #Smartphone #4G #Android #iOS #Windows #MacOS #Belgium #Brussels

0 commentaire

Laisser un commentaire

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.