Je n’ai pas donné signe de vie depuis longtemps, mais ce n’est pas pour autant que je suis resté inactifs ces derniers mois. Petit tour d’horizon de mini-projets, articles en cours ou déjà finis et autres outputs. Avec quelques petites illustrations que j’avais envie de partager.

Workshop UrbanCompint SigKDD 2014

Le premier article dans le cadre de notre projet mobilletic, celui-ci concerne l’analyse des routines temporelles des usagers des TC à Rennes. Vous pouvez trouver tous les détails dans le papier. Mais voici l’un des résultat de clustering étudié :

clusters_weighted

Article SaGEO et visualisation de matrice OD

Toujours du côté des articles mais cette fois-ci accompagné d’un petit outil. Nous avons travaillé avec Mohamed El Marhsi qui est en post-doc chez nous à une interface de visualisation de matrice Origine/Destination en particulier VLS. Celle-ci s’appuie sur des cartes de chaleurs dynamique et sur un filtrage par origine ou par destination. Nous avons profité de ce travail pour faire une communication au colloque SaGEO et mieux connaitre nos amis Géographes. L’article en preprint est accessible ici.

od

AtNight : une petit visualisation pour se faire plaisir

Du côté des visualisation pour le plaisir, nous avons fait avec un stagiaire de l’école des ponts une petite interface pour visualiser l’utilisation des Vélib’ la nuit. En appliquant la même méthode à différentes ville (Paris, New-York, Londres et Washington). Le résultat est visible par .

atNight

Article de revu, clustering fonctionel et données Vélib

Dans le champs des travaux en cours j’ai sur le feu un papier sur le clustering de données fonctionnelles avec une applications à différents système de VLS aux travers des données open data. Je devrai mettre un preprint en ligne rapidement.

realdata-clustermeansall

Présentation et autres meetup :

Enfin, si jamais certains d’entre vous ont envie de venir discuter je serai au meetup open transport organisé par la sncf et CanalTP le 18 à la fondation Mozilla. Je parlerai de vélib’ et de visualisation de données ouverte. Au mois de novembre, nous organiserons également une journée sur la fouille de données billetiques à noisy-champs. Le programme devrait être bientôt disponible.

Cours :

Du côté des cours je reprend un cours à Paris 5 en master de stats sur les outils pour l’analyse de données orienté visualisation et gestion de données. J’essayerai de partager des contenu ici au fil de l’eau.

J’ai travaillé en partie la semaine dernière sur une carto web des données carroyées que j’ai appelé francepixels. Je travail avec une doctorante sur ces données et comme elles n’avaient pas été disponibles pendant un bon moment je me suis laissé tenté. Ces nouveaux fichiers re-diffusés par l’INSEE après un petit cafouillage autour de la précédente version sont en effet assez motivant puisqu’ils fournissent des données localisées sur des carreaux de 200m de côté ! Enfin, plus précisément des groupes de carreaux de 200m dans cette nouvelle version pour assurer le degré d’anonymisation nécessaire au respect du secret statistique. Bref, à l’échelle la plus fine autorisée par nos lois, c’est à dire des groupes d’au moins 11 personnes (le max étant à 4384). Cela laisse tout de même plus 698 659 groupes de carreaux. Malgrés ces chiffres qui donnent le tournis, comme toute source de données celle-ci n’est pas parfaite, incertitudes liées à la géolocalisation des adresses des ménages français, des traitement effectués … Ces données fournissent donc une image forcément partielle mais que je trouve parlante de notre pays. J’ai donc sélectionné quelques variables qui m’intéressaient et travaillé leur représentation à différentes échelles :

– d’abord de manière assez agrégée (carrés de 4km2) :

francepixels1

– puis de manière plus fine (carrés de 200m x 200m) :

francepixels2

Je ne détaillerai pas les différentes observations que l’on peut faire de ces cartes à vous de vous faire votre idée. Je vais juste laisser ici quelques traces sur l’aspect techniques. Attention [mode geek on] ! le lecteur pourra donc s’arrêter là pour allez directement à la conclusion si ces détails ne l’intéressent pas.

[mode geek on] !

Pour construire la visualisation, j’ai d’abord fait quelques traitements en R pour produire des premières images, tester rapidement quelques échelles de couleurs et sélectionner les différentes variables que je voulais garder et représenter. J’ai ensuite fait quelques essais avec Tillemill pour produire des tuiles et développé une interface leaflet pour pouvoir jouer avec les différentes couches. Cela donnait ça. J’ai finalisé la semaine dernière en gérant les échelles fines en vectoriel et en peaufinant l’interface. Je voulais rajouter l’accès aux informations détaillées à ces niveaux de détails.

Capture-7

J’aurai sans doute pu m’en sortir avec les outils mapbox : UTF-grid + wax mais je voulais m’amuser un peu et voir comment générer des tuiles vectoriels en geoJSON avec les données et les visualiser avec leaflet et d3. J’ai fait pour cela un petit bout de code R qui sérialise un objet spatialPolygonDataFrame dans un ensemble de fichiers geojson correspondant chacun à une tuile. Chaque tuile respecte les conventions type OSM et est donc organisé dans une arborescence du type z/x/y.geojson et ressemble à un bête fichier geojson listant les carreaux de la tuile, c’est à dire leur géométrie et les variables associées comme par exemple la tuile 14/7961/5663.geojson.

Ecrire un bout de code R pour les créer n’a finalement pas été aussi difficile. Je l’ai laissé sur un gist au cas où.

Du côté client, je me suis ensuite synchronisé avec leaflet pour demander les mêmes tuiles que la couche de fond de carte et supprimer les tuiles qui ne sont plus utilisées. Pour cela j’ai simplement attrapé les événements tileload et tileunload de cette couche et y est greffé mon code d’affichage et de nettoyage des tuiles vectorielles, assez court grâce à d3 et en particulier d3.geo.path.

Forcément, cette approche est tout de même assez gourmande côté client et l’application peut donc ramer assez vite. Le compromis que j’ai choisi, tuile vectorielle à partir de l’échelle 10 avec des carreaux et 1km2 et de 200m de coté à partir de l’échelle 11. est peut être un peu ambitieuse…

Conclusion

Voilà, j’espère que ces petits travaux pourront être utiles et j’espère donc que vous n’hésiterez pas à l’utiliser! J’ai cru comprendre que l’on essaye en ce moment de définir de nouvelles ZUS, et que ces données peuvent participer à ce débat …

Bonne exploration!

Afficher des tuiles et + encore : Leaflet

Leaflet
Leaflet-Tutos
Leaflet-Choroplèthe

Serveurs de tuiles

Stamen maps
OSM fr

Créer ses tuiles : Tilemill

Presentation
carto CSS
Vue d’ensemble Tilemill + Mapbox
tilemill docs
http://mapbox.com/blog/customizing-geography-class/

Travailler avec des données OSM

imposm
TileMill+OSM
Une de mes notes de blog
Récupérer des données en SHP…

Héberger ses tuiles

mbtiles-php

D3 et carto

les projections en d3
d3 + leaflet
SHP -> geojson
choroplèthe en d3
Topojson
Cartogram + topojson

Tuiles vectorielles

Exemples
en d3
mapbox

Blogs etc …

thematicmapping
géotribu
simonmercier

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 !