monrer.fr : Quelques nouvelles et projets futurs

Cela fait certes un bon moment que je n'ai pas écrit de billet sur monrer.fr. Il faut avouer que le site Web n'a connu que peu de dysfonctionnements (de ce que j'ai pu voir, en tout cas). J'ai eu peu de temps également cette année pour le faire réellement évoluer. Il n'y a pas non plus eu de grands bouleversements côté SNCF et Open Data de manière générale.

Je pense malgré tout qu'un petit billet à propos de ce petit site est le bienvenu, histoire quand même de traiter les quelques évolutions que j'ai faites et ce que j'envisage dans l'avenir.

Un exercice de responsive design

Jusqu'à récemment, je faisais encore partie des quelques réfractaires qui ne voyait pas l'utilité d'un smartphone. Mais j'ai fini par craquer, entre autres à cause de la mauvaise qualité de construction de mon précédent téléphone.

J'ai cependant fait l'acquisition d'un smartphone durant l'été dernier, et cela a été l'occasion pour moi de reprendre le design du site. Il avait en effet un grand besoin d'être refait en « responsive design », c'est-à-dire être capable de s'adapter dynamiquement en fonction de la largeur de l'écran. Ainsi, le site devient (à peu près) utilisable sur un smartphone.

Ce n'est pas encore parfait à mon goût, mais étant donné que je partais d'assez loin, c'est toujours mieux que rien.

Ce que donne monrer.fr sur mobile.
Ce que donne monrer.fr sur mobile désormais.

Les quotas d'appels d'API

Rappelons cependant que les horaires temps réel de la SNCF sont fournis par une API Open Data que le site Web interroge dès qu'un visiteur demande de voir les horaires d'une gare particulière. Or l'accès à cette API est limité à 20 appels par minute, ce qui impose de mettre en œuvre des dispositifs afin de pouvoir assurer un service de qualité pour le plus de monde possible.

Pour m'assurer de cela, j'utilise depuis un moment un outil me permettant de surveiller l'utilisation de mon quota d'appels API, dont voici un exemple.

Statistique d'appels d'API sur
monrer.fr
En orange clair, le nombre d'appels d'API que j'aurais envoyé à la SNCF si je n'avais aucune mise en cache (cf. infra). En orange foncé, le nombre d'appels d'API que j'effectue réellement. Le maximum de 140 requêtes reçues correspond grosso modo à 28 utilisateurs simultanés.

Les mesures techniques que j'ai mises en place consistent principalement en des mécanismes de mise en cache assez agressives mais qui donnent jusqu'à maintenant pleinement satisfaction. Je vais les détailler dans la section qui suit.

Mécanismes de mise en cache

La principale mesure technique, qui m'a permis jusqu'à maintenant de faire le maximum avec cette API, consiste à mettre en cache les résultats affichés sur le site. Ainsi, lorsque n personnes demandent simultanément la même gare, le site effectue une requête API SNCF pour la première personne, effectue les calculs de retard et autres traitements avant affichage, puis met en cache le résultat côté serveur. Ainsi, les n – 1 autres utilisateurs reçoivent une copie de ce qui a été mis en cache pour le premier. Étant donné que l'affichage de monrer.fr est rafraîchi toutes les 12 secondes, cela permet de servir n personnes en n'utilisant que 5 appels API par minute au lieu de 5n.

Cette première mesure technique permet donc de passer de 4 utilisateurs simultanés à un nombre illimité d'utilisateurs consultant au maximum 4 gares différentes.

La seconde mesure technique permet, pour un nombre n d'utilisateurs consultant une gare, de passer de 5 appels à un seul appel API par minute. En effet j'ai constaté que la SNCF met à jour les horaires temps réel une fois par minute. Afin de garder les données les plus fraîches possibles, je sollicite toujours l'API 5 fois par minute tant que les données renvoyées ne changent pas, puis je passe à 1 appel par minute dès la première différence. Autrement dit, le temps d'expiration du cache passe de 12 à 60 secondes.

Ce second mécanisme me permet donc de passer de 4 consultations de gares différentes simultanées à un nombre variant entre 4 et 20 sans pour autant trop perdre en délai.

Horaires temps réel du RER A et B : hélas pas pour tout de suite

Étant donné que les grands absents des horaires temps réel Open Data restent toujours ceux du RER A et B, j'ai contacté la RATP il y a un peu plus d'un mois pour savoir où en était une éventuelle mise à disposition. On m'a répondu que cela faisait partie de leurs souhaits mais qu'il ne leur était pas encore permis de le faire. J'espère bien entendu pouvoir vous faire profiter de ces horaires temps réel dès qu'ils sont disponibles et j'espère également pouvoir être au premier rang comme lorsque la SNCF était en train de mettre le système en place il y a deux ans.

Je dispose néanmoins des horaires théoriques pour ces deux lignes du RER, mais il m'est donc impossible pour le moment d'afficher les heures de passage prévus de chaque train, compte tenu de leur éventuel retard.

En conclusion : vous êtes de plus en plus nombreux…

Depuis le début du mois de septembre, vous êtes de plus en plus nombreux à utiliser ce site ; si bien que les dépassements de quota sont parfois quotidiens (cf. supra). Le principal symptôme est que le site n'affiche que les horaires théoriques de temps à autres.

J'ai essayé plusieurs fois de contacter le responsable Open Data Transilien (j'en profite pour le saluer au passage) afin de discuter d'un éventuel assouplissement de ce quota pour moi, mais je n'ai hélas reçu aucune réponse.

Je me retrouve maintenant face à une multitude d'options pour que monrer.fr puisse continuer à croître et à être utile pour le plus de gens possibles tout en limitant les abus. Ce que je voyais initialement comme un jouet semble plaire à d'autres et je vois cela comme un encouragement pour continuer.

Posté par x0r à 25 commentaires • Tags : monrer transilien sncf open data ratp

Commentaires

Poster un commentaire

#2 — x0r

Tiens, je ne connaissais pas. On dirait une version consolidée des informations de la SNCF, de la RATP et d'autres acteurs. J'utilise déjà le jeu de données équivalent de la SNCF, qui contient aussi les horaires théoriques du RER A et B. Mais merci quand même ! :)

Cela dit je me rends compte que je me suis mal exprimé dans mon billet et je vais de ce pas le rectifier : en réalité je dispose bel et bien des horaires théoriques du RER A et B, mais uniquement les horaires théoriques. C'est juste que je ne peux pas encore afficher les horaires « temps réel » tels qu'indiqués sur les écrans de la RATP, c'est-à-dire les horaires compte tenu du retard de chaque train.

#3 — Lucas

Contrairement à ce que tu dis de ton projet sur bitbucket, il est loin d'être inutile ! D'autant plus que depuis quelques jours le site transilien ne permet plus d'accéder directement aux horaires d'une gare : clic-clic-clic et l'URL ne reflète pas les choix, elle est bloquée à http://www.transilien.com/horaires/prochains-departs .

Moralité, ton site devient presqu'indispensable, et une fonctionnalité très utile à implémenter serait de pouvoir filtrer les trains par gare d'arrivée, ou au moins par sens (vers/depuis Paris) ! (Mais avec le quota de requêtes ça risque d'être impossible...)

Bravo !

#4 — Denis F

Effectivement, transilien a fait du design !

C'est devenu la merde et on est obligé de "curler" l'url afin d'avoir les trains au départ d'une gare car les paramêtres ne sont acceptés qu'en mode POST.

#5 — Lucas

@ Denis F : si tu peux m'expliquer en quelques mots comment faire, ça m'intéresse hautement !

#6 — steph

j'imagine qu'il doit etre possible de faire un petit smart grid sur l'api avec plein de volontaire, histoire de rester sous les quota. vu le nombre de geek avec des serveurs a droite a gauche ca doit etre possible, de le coder je sais pas :).

je viens de lire les CGU rien ne s'y oppose

#7 — x0r

Une autre idée serait tout simplement de faire du round robin sur plusieurs identifiants à l'API. Ce serait beaucoup plus simple à faire, théoriquement, mais je préfère ne pas recourir à ce genre de solutions.

#8 — Lomanic

Bonjour x0r, j'utilise monrer.fr depuis un bon moment déjà et il m'est bien utile.

Il me semblait que quand tu aspirais le site web mobile sncf.mobi tu avais les infos du trafic que tu affichais en bas de monrer.fr (dans le cadre où tu indiques aujourd'hui que les horaires des lignes A et B sont théoriques ?), est-il prévu de (re)mettre cela en place ? Au cas où et si l'envie t'en prend, j'ai trouvé au moins deux sources pour de telles informations : Un flux RSS officiel sur vianavigo : https://www.vianavigo.com/fr/actualites-trafic/rss-vianavigo-vos-transports-en-commun-en-ile-de-france-optile-ratp-sncf/?type=102 (il y en a deux autres pour les actualités et les travaux à venir sur https://www.vianavigo.com/fr/actualites-trafic/) Un JSON pour les RER A, B, les métros et les tramways sur ratp.fr : http://www.ratp.fr/meteo/ajax/data

Bonne continuation.

#9 — jlouis

Bonjour Xor, j'ai découvert montrer.fr il y a peu de temps. Belle appli.

Par contre suite à la mise à jour du 21 janvier, il se trouve que la gare qui m'interresse (Nanterre université) ne s'affiche plus pour la SNCF (code NUN). Elle ne marche que pour le RER (code NC7).

Encore bravo.

#10 — x0r

Tiens, en effet, les trains pour NUN n'apparaissent plus. J'interrogeais pourtant l'API SNCF avec le bon code UIC.

On dirait que c'est un bug côté SNCF, parce que c'est l'API temps réel qui ne renvoie pas de résultats. Pas même un code d'erreur…

#11 — Maxidoudou

Bonjour et bravo pour l'appli.

Mais j'ai un bug lorsque que je sélectionne Paris Austerlitz.

#12 — Jerome

Bravo pour ce super site !

Je le trouve tellement bien que j'ai téléchargé le code source pour l'intégrer à mon site domotique fait maison pour avoir les horaires de trains toujours sous la main sans avoir à ouvrir de nouvel onglet.

Tout s'est plutôt bien passé pour l'intégration mais je bute sur une erreur au runtime que je ne sais pas expliquer: Undefined subroutine &Dancer::Plugin::Redis::plugin_args called at /usr/local/share/perl/5.14.2/Dancer/Plugin/Redis.pm line 26.

Je suis preneur de tes conseils pour réussir à corriger ce dernier problème de config avant de pouvoir enfin en profiter tous les matins et éviter les retards au boulot :)

Merci d'avance.

#13 — x0r

Comment as-tu installé le plugin Redis de Dancer ? Via ton gestionnaire de paquets, via cpan ou autrement ? Sous Linux ou FreeBSD ?

#14 — Jerome

Merci pour ta réponse. Je suis sous rasbian. J'ai installé le plugin via cpan : sudo cpan -fi Dancer::Plugin::Redis

#15 — Olivier77

Bonjour, Je suis sous Rasbian. L'installation s'est déroulée sans probléme. Mais je ne trouve pas comment accéder au site sur mon serveur. Merci pour votre aide.

#16 — sam

bonjour magnifique site il n'y a pas les horaires de gare du nord ligneH merci. bonne continuation.

#17 — sam

Bonsoir petit sousis on ne peux pas avoir les horaires des trains de la ligne L et J en temps réel à Houilles Carrières merci pourtant ligne L e J sont des lignes transilien

#18 — sam

Bonjour j'ai une petite question à propos de monrer.fr

j'ai appris que la RATP avait enfin fait Open data.

Vous pensez que l'on pourra bientôt avec les vrai horaires du RER A ET B ? votre site est juste géniale merci encore bonne année

#19 — x0r

Ça fait quelques années déjà que la RATP propose des jeux de données en Open Data, et ils viennent tout juste de commencer à proposer les horaires temps réel des RER A et B. Il faudra juste que je trouve le temps de développer ça, ce qui n’est pas vraiment évident en ce moment…

#20 — Sam

très bien merci pour votre réponse bon courage

et vous savez pourquoi ne n'arrive pas à trouver les horaires de la ligne H à Paris Nord ?

#21 — tom

Bonjour savez vous si lorsque que le RER A et RER B seront intégré en temps réel il y aura comme pour les autres lignes SNCF les temps de retards ? et ,si

Vous avez une petite idée du temps qu'il vous faudra pour faire tout ça ?

merci

j'adore votre site :)

#22 — sam

Bonjour

J'ai une idée

Quand un train est affiché retardé pourquoi ne pas faire le retardé clignotant avec son heure de départ théorique

#23 — sam

Bonjour

il n'y a plus du tout les horaires même théorique des lignes À et B :(

savez vous pourquoi svp ? merci

#24 — Kev

Bonjour,

Tout d'abord super boulot, c'est vraiment très représentative des écrans SNCF affichés en gare. C'est super d'avoir mis le code source en ligne, ça nous permet de voir tu as hard codé ça ;)

J'ai une petite question : Ce serait possible d'intégrer toutes les lignes de RER pour l'arrêt Val de Fontenay (RER A + RER E) directement dans une seule vue comme pour Gare de Lyon par exemple qui t'affiche plusieurs lignes en une seule vue. L'idée serait d'ajouter un écran au boulot :) Cela permettrait d'éviter d'afficher deux pages ^^

Merci à toi ;)

#25 — Gilles

Bonjour, Votre "travail" est magnifique. Comme je fais parti d'une association de tain touristique, je voulais présenter "nos" circulations en utilisant cette présentation. J'y suis maintenant parvenu. J'ai repris la page html et les différents css. Par contre, comme cela devait être hébergé sur un site où je ne fais pas ce que je veux, j'ai bidouillé pour faire en sorte que cela fonctionne, avec du php et une base Mysql. J'ai aussi repris l'idée de raildar d'ajouter les retards et leurs motifs. Voici donc le résultat : https://attcv.fr/affiche_gare/

Poster un commentaire