Mise à jour du 14 août 2021 : la migration s’est déroulée sans encombres. Merci pour votre patience !

Mise à jour du 9 août 2021 : ajout d’un paragraphe sur les numéros des trains du RER D (sujet que j’avais oublié de traiter dans une version précédente de l’article).

Ça fait déjà huit ans depuis que j’ai ouvert le site monrer.fr et il était temps que je reprenne un peu ce vieux projet, sur lequel j’avais communiqué pour la dernière fois en novembre 2015, pour y corriger de vieux problèmes latents.

Il m’a fallu beaucoup de temps pour retrouver ma motivation pour faire évoluer le site. D’abord parce que pendant longtemps, je n’avais plus trop envie de coder sur mon temps libre : c’était déjà mon activité principale pendant mes horaires de travail. D’autres limitations imposées de l’extérieur m’ont également frustré (et me frustrent encore), comme le quota d’appels de l’API Temps Réel Transilien qui est de 20 par minute et dont j’ai déjà parlé auparavant.

Mais plusieurs changements plus ou moins récents m’ont redonné suffisamment d’inspiration pour revenir sur ce projet.

Premièrement, chez mon employeur, je suis passé du domaine du développement logiciel à celui de l’ingénierie système il y a quelques années. Deuxièmement, j’ai découvert l’excellent ouvrage The Art of PostgreSQL (2^e édition) de Dimitri Fontaine : les exemples m’ont émerveillé, et ce dès la page 16. Troisièmement, pour la première fois depuis la fin de mes études, j’ai pris trois vraies semaines de congé consécutifs.

Enfin, et pas des moindres : pendant ma première semaine de ces congés, un utilisateur de monrer.fr, qui me contacte déjà régulièrement lorsque le site rencontre un problème, m’a signalé un nouveau souci. J’avais en effet un bug dans une requête SQL qui doit récupérer les horaires théoriques de passage des prochains trains à une gare donnée et à un instant donné ; ce bug ne se manifestait que dans des cas très précis, notamment lors de services dégradés mis en place durant des phases de travaux estivaux. Alors quitte à remettre la main à la pâte pour corriger ce bug en particulier, autant en profiter pour résoudre d’autres problèmes plus structurels dus à des choix techniques plus ou moins discutables que j’ai faits il y a huit ans.

Accélération de la recherche des horaires théoriques

Par exemple, la recherche des horaires théoriques prenait une à deux secondes en MySQL, ce qui mettait parfois la machine à genoux durant des périodes de forte charge. Mes nombreuses soirées passées à décortiquer les sorties de commandes EXPLAIN et à indexer mes tables ont été autant d’efforts qui ne se sont pas traduits par des gains de temps spectaculaires. Par ailleurs, je souhaitais aussi avoir non seulement la liste des trains passant à une gare donnée, mais aussi, pour chaque train, la liste complète des prochains arrêts et le nom de son terminus, ce que je faisais en exécutant six fois une autre requête.

Mais en PostgreSQL, entre autres grâce à la fonction array_agg() qui me permet d’agréger un ensemble de données dans une colonne de type tableau, et aux window functions, qui me permettent d’examiner les tuples voisins dans le résultat de la même requête, je suis parvenu à une seule requête qui, en seulement 40 ms, me donne toutes les informations d’un seul coup. L’introduction d’un seul index a été décisif pour accélérer cette requête.

Par conséquent, les temps de chargement devraient être considérablement réduits pour les gares des lignes A et B, pour lesquels je ne dispose pas encore des horaires temps réel. Mais ça aussi, ça va changer.

Obtention d’accès pour l’API Temps Réel de la RATP

En effet, un autre défaut latent de monrer.fr est l’absence d’horaires temps réel pour les lignes A et B du RER. À l’époque, la RATP ne les mettait pas encore à disposition. Ça a changé depuis plusieurs années déjà, donc il ne me restait plus qu’à faire les démarches pour obtenir les accès à l’API Temps Réel RATP. Ce ne sera pas encore pour tout de suite, car l’intégration de cette API avec mon code existant est une tâche qui s’annonce complexe : la FAQ explique par exemple que le rapprochement entre les résultats de cette API et les horaires GTFS doit être faite d’après les noms des gares ; une solution qui ne me plaît guère.

Unification des gares

J’avais fait jadis l’hypothèse que chaque gare répertoriée dans mon site a un unique code TR3 (à trois lettres) et un seul code UIC (sept ou huit chiffres, utilisé comme clef par l’API Temps Réel Transilien). Cette hypothèse s’est rapidement avérée fausse, notamment :

• lorsque la même gare dessert le RER A ou B (RATP) d’une part et une ligne RER ou Transilien exploitée par la SNCF d’autre part, comme Massy – Palaiseau ou Massy – Verrières ;

• dans le cas des grandes gares parisiennes, où la partie « grandes lignes » et la partie « banlieue » ont des codes UIC différents, comme à Paris Gare de Lyon ;

• ou encore quand on cumule ces deux propriétés, comme Paris Nord.

J’avais d’abord contourné le problème en dédoublant les gares concernées, ce qui n’a jamais marché de façon satisfaisante. Il fallait donc absolument revenir sur cette hypothèse.

Pour cela, il fallait donner à chaque gare un identifiant neutre, pouvant être associé à un ou plusieurs codes UIC mais servant de point d’entrée principal pour identifier une gare du point de vue d’un voyageur.

Par conséquent, il n’y a plus besoin de choisir entre « Massy – Palaiseau RER B » et « Massy – Palaiseau RER C » lorsqu’on veut les prochains départs à la gare de Massy – Palaiseau : il n’y a plus qu’un seul « Massy – Palaiseau » et les résultats peuvent ensuite être filtrés par ligne comme n’importe quelle autre gare.

Bascule du format des horaires GTFS

J’en profite aussi pour basculer sur le nouveau format GTFS que la SNCF propose depuis peu pour son export des horaires théoriques. La loi d’orientation des mobilités (LOM) les ont en effet amenés à bifurquer cet export GTFS en un « ancien format » et un « nouveau format ».

À première vue, le nouveau format semble plus facile à exploiter pour moi : les numéros des trains (six chiffres pour un train d’une ligne SNCF et quatre lettres + deux chiffres pour un train d’une ligne RATP) sont désormais renseignés dans le champ trip_short_name de la table trips. Je n’ai donc plus besoin de faire de honteux bidouillages avec les identifiants trip_id comme je le faisais jadis. De toute manière, ces trip_id sont devenus des identifiants opaques.

Le seul inconvénient est que le rapprochement avec les gares est un peu plus compliqué car les identifiants des gares (stop_id) ne sont plus dérivés des codes UIC, mais il est possible d’obtenir une table de transcodage entre les identifiants qu’on trouve dans le GTFS et le code UIC.

Quant aux trigrammes des gares, il existe maintenant une source en Open Data : le Lexique des abréviations SNCF. La liste n’est pas complète, mais j’ai néanmoins pu corriger quelques gares prises au hasard pour lesquels le code à trois lettres était incorrect ou m’était inconnu. Mais le rapprochement entre ma propre base de données et le lexique officiel afin de vérifier et éventuellement corriger toutes les gares qui y sont répertoriées sera un projet pour plus tard.

Affichage correct des numéros de train du RER D

En règle générale, les trains ayant un numéro impair s’éloignent de Paris et ceux ayant un numéro pair s’en rapprochent. Ce qui donne aussi le nom au sens de circulation sur une ligne de chemin de fer, qu’on désigne par « pair » et « impair ».

Mais les numéros des trains du RER D sont particuliers car les trains traversant Paris changent du numéro entre Paris Gare de Lyon et Châtelet – Les Halles, un fait qui m’a longtemps posé problème pour le rapprochement entre horaires temps réel et horaires théoriques (et qui, visiblement, a aussi provoqué des dysfonctionnements du côté des vrais écrans Infogare il y a longtemps). Par exemple, un train à destination de Villiers le Bel, portant le numéro 126658 à son départ de Corbeil-Essonnes, devient le 126659 lorsqu’il quitte la Gare de Lyon pour Châtelet – Les Halles. De même, le train 153692 partant de Goussainville à destination de Melun devient le 153693 lorsqu’il quitte Châtelet – Les Halles pour la Gare de Lyon.

Pendant longtemps, pour ces trains-là, l’API Temps Réel Transilien me donnait le numéro du train valable à la gare pour laquelle je demandais les horaires : tantôt 126658, tantôt 126659 pour le premier exemple. Mais depuis le mois de novembre 2019 environ, l’API renvoie le numéro composite 126658-126659, ce à quoi j’ai réagi par un bricolage où je gardais systématiquement le numéro pair. Depuis, les numéros des trains affichés pour les gares du RER D n’étaient pas toujours les bons.

Afin de faire les choses proprement, j’ai dû ajouter aux gares de la ligne D deux informations : un numéro d’indice unique au sein de la ligne, où ma convention a été de choisir des numéros croissants dans le sens nord-sud et un booléen qui indique un sens impair dans le sens des numéros croissants s’il est vrai et un sens pair sinon ; ce booléen est donc faux pour Châtelet – Les Halles et toutes les gares au nord de celle-ci et vrai pour Paris Gare de Lyon et toutes les gares au sud de celle-ci. Avec ceci, il m’est possible de déterminer la « parité » d’un train au passage d’une gare donnée, puis lequel des deux numéros, pair ou impair, je dois afficher. Avec ceci, les numéros des trains du RER D sont de nouveau affichés correctement.

Par ailleurs, le rapprochement entre horaires temps réel et théoriques est simplifié car les exports GTFS utilisent aussi ces numéros de train composites.

J’estime aussi que ce cas, particulier au RER D à l’heure où j’écris ces lignes, pourrait aussi concerner le RER E lorsqu’il sera prolongé vers l’ouest. Dans ce cas, je suppose que les trains changeront de parité en quittant Haussmann Saint-Lazare.

Migration prévue le week-end du 15 août

Je souhaite vous faire profiter de mes modifications le plus vite possible, mais je sais que la bascule ne se fera pas en un claquement de doigts. C’est pourquoi je serai contraint de mettre le site hors ligne quelques instants durant le week-end du 15 août prochain. Je m’excuse donc par avance des désagréments que pourraient causer cette courte indisponibilité.