Jouons au petit train [2] : La structure de données

Modifié le Feb. 8, 2019, 9:26 p.m.

Il m'aura fallut du temps pour arriver à bien comprendre la structure des données (GTFS et GTFS realtime) fournies par l'API. Mais voilà que j'y suis enfin arrivé.

Rapide résumé.

Pour commencer, on a deux types de données :

  1. Les données planifiées
  2. Les données en temps réel.

Les données planifiées sont structurées de la sorte :

  • Les routes : d'un départ à une destination
  • Les routes contiennent des trips : une planification donnée de l'exécution de cette route
  • Les trips contiennent des stop times : À quelle heure on est censé arriver à quelle gare pour une planification d'une route.

Il y a d'autres types de données mais disons que cette structure est la principale à comprendre.

Viennent ensuite les données temps réel. Là encore, plusieurs types d'entités existent (d'ailleurs le format utilise Protobuf, ce qui est super cool) :

  • Les update sur les trips
  • Les positions de trains en temps réel
  • Les problèmes de circulation

Ce qui nous intéresse principalement nous, c'est les updates sur les trips. Ceux ci contiennent toujours :

  • Les gares de départ et d'arrivée
  • Un identifiant du trip
  • Le retard sur les gares de retard et d'arrivée.

Fixer un cas d'utilisation

Un premier cas d'utilisation que j'aimerais aborder avec ces données, c'est la notification temps réel des retards du transports, ceci sous la forme d'un chat bot.

Les fonctionnalités seraient :

  • On indique ses horaires de train habituels
  • On est notifié en temps réel que le train que l'on est censé prendre aura du retard à l'arrivée à la gare de départ ou de destination
  • On peut chercher quel est le retard d'un train (sans qu'il fasse partie de nos trains habituels) quand il arrivera à une certaine gare.
  • Fonctionnement comme un chatbot multi plateforme

Trois fonctionnalités simples donc mais qui pourraient pas mal aider la vie des personnes qui voyagent tous les jours.

Des données au cas d'utilisation

Actuellement, nous n'avons que des données brutes et des requirements vagues. On a donc les deux côtés d'un point d'eau qui constituera notre logiciel. Heureusement, dans notre cas, ce point d'eau tiendra plus du lac que de l'océan.

En effet, le fait que cette application doive fonctionner comme un chatbot est maintenant un requirement courant. Je pense avoir déjà entendu parler de service permettant cela en une seule fois. On y regardera donc en temps utile. Mais au cas où ça ne fonctionnerait pas, une petite inversion de contrôle, une factory et un pattern Stratégie et le tour est joué !

Pour ce qui est des données. On sait que l'on peut reprendre les données temps réel toutes les 30 secondes. Il suffit juste donc de les parcourir et au fur et à mesure de lier les nouveautés aux demandes des utilisateurs. Le tout avec des données locales évidement pour les recherches et configurations.

Le seul "vrai" souci, c'est que la forme des données statiques ne nous arrange pas vraiment. Elle donne une structure en top down (route vers heure à l'arrêt) là où nous la voudrions en bottom up (heure en gare la vers route pour définir l'heure en gare d'arrivée). Cependant, il "suffit" (à priori) d'écrire le code permettant de faire cette inversion de l'ordre des données, de les stocker et le problème devrait être résolu.

Ainsi la structure qui nous intéresse serait la suivante :

  • Chaque gare contient les lignes qui passent par elle (en considérant la dite gare comme si elle était la première de la ligne)
  • On aurait pour chaque ligne un liste des arrêts suivants sur la ligne
  • Pour chacun des arrêts sur la ligne, on aurait les heures prévues (une par planification) de ces arrêts

Ainsi, si un utilisateur cherche le retard du train vers Tamines démarrant normalement de Charleroi à 7h12, il suffit de trouver la gare de Charleroi et de regarder parmi ses lignes laquelle à un train partant à 7h12 et passant par Tamines. Il est ainsi possible de connaitre à la fois le temps au départ de Charleroi MAIS AUSSI le retard estimé à toutes les autres gares de cette ligne et pour cette planification.

L'enregistrement des retards serait lui assez simple. Comme on a la gare de départ et d'arrivée ainsi que l'identifiant de la ligne, il suffit de trouver toutes les occurrences des heures de départ et d'arrivée pour ces gares de cette ligne et de mettre à jour leur retard. Au fur et à mesure de chaque journée, le retard de chaque planification de chaque ligne se mettra donc à jour pour qu'en fin de journée, tous les retards soient connus. Ces données pourraient ainsi être gardées en historique pour le calcul de futures statistiques.

Le seul défaut de cette structuration de l'information, c'est la duplication. En effet, chaque arrêt sur une ligne sera répliqué à priori pour chacune des gars de cette ligne. On peut le dire, cela fait pas mal de données dupliquées. Cependant, on parle bien ici d'une idée préalable et l'implémentation physique pourrait bien évidement être différente. De plus, d'après ma compréhension actuelle du problème, la structure des lignes et des arrêts changeant normalement assez peu souvent, il apparait que cette duplication ne serait, sans doute, faite qu'une seule et unique fois. Les données n'exploseraient donc pas tous les jours.

En conclusion, pour le prochain article, je tenterai de définir une structure de données permettant de mettre en place notre inversion du formatage ainsi que d'implémenter. Je suis impatient de faire cela et de vous l'écrire !