Je viens de faire les dernières corrections sur VLS&STATS.

Cette expérimentation permet d’accéder aux données historiques d’une vingtaine de systèmes de Vélos en Libre Service (VLS) comme ceux de Paris, Lyon ou New-York pour les observer à différentes échelles spatiales et temporelles. Elle a été développée à l’IFSTTAR dans le cadre d’un projet de recherche sur l’analyse des données VLS.

L’objectif principal de ce travail était de tirer partie de données historiques pour offrir un tableau de bord pertinent pour observer et étudier les systèmes de VLS (et au passage vérifier que la captation des données se passait correctement). Les données open data peuvent en effet à mon avis servir à bien d’autre chose qu’à développer des applications pour smartphones.

Elle a forcément trouver son inspiration au moins en partie dans différents autres projets tel que celui de Oliver G O’Brien bikes.oobrien.com qui a déja poussé loin le concept ou dans le vénérable v.mat.cc sur les Vélib’. J’ai pioché dans l’un et l’autre pour aboutir à ma proposition finale.

Celle-ci est construite autour de trois vues // différentes échelles que j’ai développées séquentiellement en commençant par celle qui m’inspirait le plus le tableau de bord d’une ville, par exemple Marseille. Ce tableau de bord reprend des éléments de contexte sur le système : sa taille en terme de nombre de vélos, de stations, de bornes ainsi que l’heure locale d’enregistrement. Ces statistiques n’évoluent quasiment pas (à part le nombre de vélos utilisés et l’heure) et sont donc séparées des autres et placées dans le bandeau de titre.

counter

L’interface d’exploration a proprement parlée est constituée de deux éléments. Un premier panneau sur lequel est présenté un ensemble de statistiques d’usage et de disponibilité pour l’ensemble du système ainsi qu’un graphique temporel (sur une semaine) qui présente l’évolution de la statistique sélectionnée.

plot

Ce panneau est couplé à une carte qui permet de visualiser la répartition spatiale par stations. Mais ce que je trouve vraiment sympa c’est la feature “time machine” qui permet d’animer la carte en naviguant dans l’historique avec les flèches du clavier ou “les gros boutons”. A essayer sur Paris pour observer le joli mouvement pendulaire !

mapcity

La carte permet également d’avoir les statistiques d’une station à l’instant courant et d’accéder à une vue station. En ce qui concerne les statistiques, j’ai choisi de permettre à l’utilisateur de jouer avec différents indicateurs que je voulais simples à comprendre et intéressant d’un point de vue temporel et/ou spatial. J’ai sélectionnés:

  • le nombre de bornes disponibles
  • le nombre de vélos disponibles
  • le nombre de bornes en maintenances
  • le nombre de stations pleines
  • le nombre de stations vides
  • le nombre de station fermées

Ces différents indicateurs permettent de faire le tour des données disponibles, sont normalement directement compréhensibles et mettent en exergue un aspect du fonctionnement et/ou du dis-fonctionnement du système.

J’ai ensuite développé l’interface station qui reprend en partie des éléments du tableau de bord ville: graphique temporel, carte. Cependant à cette échelle seule trois informations sont pertinentes: vélos disponible, bornes disponibles et bornes en maintenances. Je n’ai donc conservé que ces statistiques. J’ai également rajouté un graphique circulaire de l’évolution temporelle pour faire ressortir d’éventuelles régularités journalière.

vuestation

Finalement, J’ai réalisé une vue permettant de comparer les systèmes entre eux aux travers de statistiques mensuelles sur leurs:

  • Taille (le nombre de stations)
  • Usage (Estimation du nombre d’heure totale d’utilisation des vélos)
  • Rendement (Estimation du nombre d’heure totale d’utilisation des vélos, normalisé par le nombre de vélos)
  • Défaillance (% de bornes en maintenance)
  • Saturation (% de stations vides et % de stations pleines)

Cette vue reprend les conventions des autres perspectives mais à une échelle supérieure avec des statistiques plus pertinentes pour faire des comparaisons (normalisées).

somp

D’un point de vue technique l’infrastructure pour capter les données est basée sur MongoDB que je voulais essayer et sur du script bash et un petit peu de perl pour l’alimenter. L’interface wev est quant à elle construite en d3 avec une bonne dose de Leaflet et de mapbox dedans.

Voilà amusez vous bien vlsstats.ifsttar.fr !Les retours @comeetie sont bien entendus les bienvenus !

Comments are closed.