EDIT : Je n'utilise plus cette méthode pour récupérer les horaires en live pour monrer.fr, mais une autre API une API officielle fournie par la SNCF.

Depuis quelques temps, la SNCF publie certaines données sur ses trains et ses services dans une politique d'Open Data.

Certains d'entre vous ont peut-être déjà vu mon dernier mini-site qui utilise ces données pour afficher une information de ponctualité pour la grande majorité des trains. Ainsi, un train prévu pour 11 h 07 et dont l'heure de passage est de 11 h 09 est affiché avec la mention « +2 min » :

Les horaires de passage réels des trains sont récupérables par plusieurs moyens, mais les comparer avec l'horaire théorique stocké dans les exports GTFS de la SNCF nécessite de faire un certain nombre de traitements sur ces données pour les confronter correctement.

Tout d'abord, quelques définitions

Pour ne pas vous perdre tout de suite, quelques définitions s'imposent. Au risque de réutiliser des termes du jargon ferroviaire en m'éloignant de leur sens d'origine, les voici :

Sur une ligne de RER, on assure des missions : ces missions sont tout simplement des listes de gares desservies dans un certain ordre. Certaines missions sont omnibus (i.e. s'arrêtent à toutes les gares d'une ligne), d'autres sont semi-directes et sautent parfois certaines gares. À chaque mission, on donne un code à quatre lettres, appelé code mission, unique à chaque mission, et qui permet aux régulateurs de connaître exactement la desserte d'un train donné, afin de l'aiguiller correctement. On montre également ces codes mission aux voyageurs.

Toutes les missions sont assurées à intervalles réguliers par des trains qui ont pour ordre de s'arrêter à chaque gare de leur mission en respectant un horaire théorique. Les aléas de la circulation amène souvent ces trains à accuser un retard, et on indique alors sur les écrans d'information des gares Transilien une estimation de l'horaire réel de passage d'un train dans une gare donnée.

Chaque train est repéré, en zone SNCF (lignes RER C, D, E et Transilien) par leurs numéros de train (par exemple, 123477), et en zone RATP (lignes RER A et B) par leur code mission à quatre lettres suivi de deux chiffres (par exemple, ZEUS67).

L'ensemble des trains circulant un jour donné constitue un service journalier. Souvent, on assure des services journaliers différents en semaine et en week-end ; les horaires théoriques du week-end pouvant être moins contraignants qu'en semaine, où l'on fait rouler un nombre plus conséquent de trains.

Enfin, afin de rester cohérent avec les termes utilisés dans l'export GTFS, j'appelle un itinéraire un train qui, un jour donné, assure une mission donnée. Le train 123477 un jour de semaine n'est pas forcément le même que le 123477 un samedi ou dimanche ; cependant, ces deux itinéraires sont repérés par des identifiants différents, par exemple DUASN123477R010392834 et DUASN123477R040392235.

Les sources de données de mon mini-site

J'utilise deux sources de données pour afficher les informations visibles sur le mini-site.

La première source donne tous les horaires théoriques de tous les trains que la SNCF fait rouler sur son réseau Transilien. Les gares sont repérées par leur code UIC ; la correspondance entre code UIC et nom de gare est fournie dans les données exportées. Ces données sont disponibles sur la page Transilien du site OpenData SNCF sous forme d'une archive zip qui, une fois extraite, donne ces informations dans ce fameux format GTFS dont je parle depuis le début de ce post.

La seconde source, en revanche, me donne les horaires réels des prochains trains d'une gare repérée à l'aide d'un trigramme appelé « TR3 » (exemple : SKX pour Sceaux, PAA pour Paris Gare de Lyon (RER D), COE pour Corbeil-Essonnes...). La liste officielle de ces trigrammes et la correspondance avec le nom de la gare est a priori un document interne à la SNCF, mais comme pour les codes UIC, on trouve assez facilement des listes (incomplètes) compilées sur Internet. J'ai dû passer pas mal de temps pour compléter cette liste, donc je vous propose d'aller regarder le code source et d'ouvrir le script db.sql.

Cette source n'est a priori pas publiée sous licence Open Data, mais l'URL a l'air de se balader un peu partout dans des forums. L'URL est de la forme :

http://sncf.mobi/infotrafic/iphoneapp/transilien/?gare=[trigramme gare]

et les données obtenues sont en JSON, exploitable quasi-directement dans un script, pourvu que l'on ait quelque part une base de données de gares indexées selon leur code TR3.

Utiliser les deux sources ensemble

Les problèmes principaux que j'ai eus en voulant utiliser les deux sources ensemble étaient les suivants :

• L'export GTFS mentionne des identifiants d'itinéraire du style DUASN123477R010392834, alors que les horaires en temps réel ne donnaient que le numéro du train, du style 123477. On peut dériver le numéro du train en fonction de l'identifiant d'itinéraire, mais dans l'autre sens, comme dans mon cas, un train peut correspondre à plusieurs itinéraires ; on est donc obligé d'utiliser une clause WHERE un peu compliquée pour éliminer les itinéraires qui ne correspondent pas au jour actuel, entre autres.

• Dans certains cas, les numéros de trains dérivés des identifiants d'itinéraire n'existent pas. En particulier avec certaines mission ROPO du RER D, ou certaines mission du RER C, où il faut aller chercher le numéro de train « à côté » pour avoir les données que l'on cherche.

• Les horaires fournis dans l'export GTFS dépassent parfois 24 h. Un train qui part de sa gare d'origine à 23 h 50 et qui arrive à son terminus à 1 h 50 est noté comme arrivant à 25 h 50 dans les données GTFS. En revanche, le train assurant la même mission et qui part une demi-heure plus tard (à 0 h 20, donc) est noté comme arrivant à 2 h 20 au lieu de 26 h 20. Je comprends le raisonnement derrière, mais ça reste fastidieux à gérer.

• L'export GTFS utilise les codes UIC des gares desservies par chaque train, alors que les données « temps réel » n'utilisent que les codes TR3. Heureusement, faire une table qui indexe les gares à la fois par leur code UIC et leur code TR3 n'est pas non plus la chose la plus compliquée du monde.

Conclusion

En soi, la seule chose que je regrette avec les données GTFS de la SNCF, c'est qu'il manque les numéros de trains, et que je suis obligé de les dériver d'un identifiant à l'aide d'un hack que je considère comme infâme. À part ça, cela me fait extrêmement plaisir que la SNCF ait décidé de faire un pas vers la libération de ses données, et même si la RATP a également emboîté le pas, ils ne publient pas les mêmes informations.

Néanmoins, j'espère avoir réussi à démystifier un peu cette application Web. Je tire néanmoins une grande fierté de pouvoir afficher sur ce mini-site des informations que même les écrans Infogare n'affichent pas ; on constate parfois à quel point certains trains accusent du retard en heure de pointe, même si ce n'est plus aussi visible qu'avant.

En confrontant ainsi données théoriques et informations de circulation en temps réel, ce serait là l'occasion pour des chercheurs ou des groupes de travail divers et variés de collecter des données de régularité et ainsi, peut-être, en tirer des conclusions qu'il serait impossible de tirer autrement ?

Et en bonus

Un petit truc marrant qu'on peut s'amuser à faire avec ces données GTFS : tracer le nombre de trains en service en fonction de l'heure de la journée sur chacune des lignes RER/Transilien SNCF (cliquez pour voir en grand et en meilleure qualité) :

Suite : monrer.fr : autocomplétion et reverse-engineering