Un petit post pour partager ma présentation au meetup open transport du 18 Septembre.

meetup

Et également pour faire de la pub pour la journée Data Analytics and Visualization in Transport que nous organisons le 10 Octobre prochain à Marne-la-vallée. Le programme complet est disponible par .

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.

Premiers pas avec les données de billetiques de Rennes pour le projet #mobilletic. Pour commencer, deux petites cartos animées du volume de validations par stations sur une semaine. Dans l’aire urbaine :

pulseRennes

Zoomé sur le centre ville :

pulseRennes

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 !

Comme je travail en ce moment beaucoup sur les déplacements vélo j’ai voulu réaliser une carte orientée cyclisme, qui mettent en avant les équipements cyclable (” la cyclabilité des voies “) et le relief (même faible). Et comme beaucoup de choses autour de cette question se font actuellement (cf appel d’offre de la région ile de france, arrivé du fond de carte google maps “A vélo”,…), j’ai voulu voir ce qu’on pouvait faire avec des outils open sources, des données ouvertes ou en tout cas auxquelles j’avais accès et un peu de bonne volonté. Le résultat actuel de mes tests est accessible ici.

carte vélo ile de france

Les différents équipements cyclables : piste cyclable, bande cyclable, zone 30, couloir de bus, … sont représentés avec une légende de type carte routière les équipements les mieux adaptés en couleurs + sombre et + large et le relief est rendu grâce à un ombrage. Les choix fait pourrait sans doute être améliorés mais c’est un premier jet.

Je laisse quelques notes techniques sur ce travail de manière à garder une trace et pouvoir m’y retrouver lorsque je réutiliserai ou modifierai ce fond de carte. J’ai utilisé les données OSM et des données de relief de l’IGN (la BD ALTI). J’ai combiné ces deux sources à l’aide de quelques outils, s’articulant autour de TilleMill :

  • imposm : pour importer les données OSM dans une base de données pgsql
  • TileMill : pour créer les tuiles de la carte en appliquant des feuilles de style carto-css
  • gdal : pour créer des images ratser à partir de données d’élévation (pour rendre le relief)

Voici quelques éléments sur la méthode utilisée pour obtenir ce résultat et quelques liens glanés au cours de cette expérimentation.

Prise en main de TileMill

Pour commencer, j’ai créer un projet Tillemill relié à des données open street map en suivant le guide fourni par mapbox. Celui-ci permet de mettre en place un projet TilleMill connecté à une base de données pgsql contenant les données OSM importée (via imposm). Le projet TilleMill contient un ensemble de requêtes sql définissant des calques et un ensemble de feuilles de style carto-css définissant la représentation de chacun de ces calques, c’est à dire comment ceux-ci sont représentés sous forme de lignes, de surfaces ou de points. Le fonctionnement est donc assez intuitif : vous gérer vos calques, leur ordres et leurs représentation grâce à un language de type css dans une interface plutôt ergonomique. Un élément simple peut ainsi être définis en quelques lignes :

#countries {
  polygon-fill: #fff;
  polygon-opacity: 0.75;
}

Créer ses propres calques et les mettre en formes

J’ai ensuite modifié l’importation des données dans la base pgsql pour récupérer les informations sur les équipements cyclables qui m’intéressaient en rajoutant dans le fichier python utilisé par imposm (imposm-mapping.py) une nouvelle table pour les équipements cyclables.

cyclelanes = LineStrings(
    name = 'cyclelanes',
    mapping = { 'cycleway': (
            'lane',    
            'track',    
            'opposite_lane',   
            'opposite_track',  
            'opposite',
            'shared',
            'share_busway',
            'shared_lane',
            'sharrow',
            ),
        },
        fields = (
            ('tunnel', Bool()),
            ('bridge', Bool()),
            ('oneway', Direction()),
            ('ref', String()),
            ('layer', Integer()),
            ('z_order', WayZOrder()),
            ('access', String()),
            ('highway', String()),
        ),
)

Cela m’a permis de rajouter un nouveau calque pour les infos qu’il manquait dans TilleMill à partir des données de cette table. Ce nouveau calque est simplement défini en utilisant une requêtes du type :

( SELECT geometry, type, name, tunnel, bridge, oneway, ref, layer, z_order, access, highway
    FROM osm_cyclelanes
) AS data

J’ai ensuite mis en forme ce calque grâce aux possibilités de TilleMill suivant le niveau de zoom le type d’équipement …, j’ai également modifié le style des routes de bases de manière à rendre la carte un peu plus lisible. A titre d’exemple voici quelques extrait du code carto-css utilisé pour visualiser les équipements cyclables.

#cyclelanes::outline {
  line-width:5;
  line-cap: round;
  line-join: round;
  line-color:@cycle_case4;
  [type='share_busway']{
  line-color:@cycle_case3;
  }
  [type='opposite']{
  line-color:@cycle_case2;
  }
  [type='lane']{
  line-color:@cycle_case1;
  }
      /* -- widths -- */
  [zoom=11] {
    [type='lane'] { line-width: @rdz11_med + 1.6; }
    [type='share_busway']{ line-width: 0.2 + 1.6; }
    [type='opposite']  { line-width: 0.2 + 1.6; }
  }

.....

  [zoom>=18] {
    line-width: @rdz13_min / 3 + 4;
    [type='lane']   { line-width: @rdz18_med + 4; }
    [type='share_busway']{ line-width: @rdz18_min + 4; }
    [type='opposite']   { line-width: @rdz18_min / 2 + 4 ; }
  }
 
 
}
#cyclelanes {
 
  line-cap: round;
  line-join: round;
  line-color:@cycle_fill4;
  [type='lane']{
  line-color:@cycle_fill2;
  }
  [type='share_busway']{
  line-color:@cycle_fill3;
  }
  [type='opposite'],[type='opposite_lane']{
  line-color:@cycle_fill4;
  }
    /* -- widths -- */
  [zoom=11] {
    line-width:0.2;
    [type='lane'] { line-width: @rdz11_med; }
    [type='share_busway']{ line-width: 0.2; }
    [type='opposite']  { line-width: 0.2; }
  }

 ...

  [zoom>=18] {
    line-width: @rdz18_min / 4;
    [type='lane']   { line-width: @rdz18_med; }
    [type='share_busway']{ line-width: @rdz18_min; }
    [type='opposite']   { line-width: @rdz18_min / 2; }
  }
}

Générer un raster pour le relief et l’inclure dans TilleMill

Pour finir j’ai joué avec gdal pour créer des raster rendant le relief. Je me suis inspiré du tutoriel proposé par mapbox en le modifiant pour exagérer le relief. J’ai en particulier modifié l’ombrage des pentes de manières à ce que même les pentes faibles < 10% soient visibles. Celles sont en effet intéressantes pour le cycliste. J'ai pour ce faire re-projeter les données IGN avec gdalwrap et construit un raster d'ombrage avec hillshade :

gdaldem hillshade -co compress=lzw  -z 3 bdalti-iledefrance-3785.tif hillshade-iledefrance-z3-3785.tif

puis calculer la pente avec gdal slope:

gdaldem slope  bdalti-iledefrance-3785.tif slope-iledefrance-3785.tif

afin de produire un autre raster d’ombrage, en utilisant une rampe de valeur personnalisées :

gdaldem color-relief -co compress=lzw slope-iledefrance-3785.tif sloperamp.txt slopeshade-iledefrance-3785.tif

Finalement, j’ai importé ces deux raster dans des nouveaux calques TilleMill et je les ai combinés avec la carte construite à partir des données OSM en utilisant l’opération de combinaison par multiplication offerte par le mode raster de TilleMill (Ces deux calques étant placé en haut de la pile de calques).

#slope-shade,
#hill-shade {
    raster-scaling: bilinear;
    // note: in TileMill 0.9.x and earlier this is called raster-mode
    raster-comp-op: multiply;
}

#hill-shade { raster-opacity: 1; }
#slope-shade { raster-opacity: 0.7; }

J’essayerai de retravailler ce fond de carte dans le futur pour pouvoir l’exploiter mais cette découverte de différents outils de carto numérique était en tout cas fort enrichissante …

We finally (me and Pierre Latouche) released our preprint on graph clustering with stochastic block model when the number of cluster is unknown. In our proposal this is solved thank to a model selection approach based on the integrated complete data log likelihood. Algorithmic issues to perform clustering and model selection at the same time are also discussed. It his availbale at arXiv or here and the abstract follow:

The stochastic block model (SBM) is a mixture model used for the clustering of nodes in networks. It has now been employed for more than a decade to analyze very different types of networks in many scientific fields such as Biology and social sciences. Because of conditional dependency, there is no analytical expression for the posterior distribution over the latent variables, given the data and model parameters. Therefore, approximation strategies, based on variational techniques or sampling, have been proposed for clustering. Moreover, two SBM model selection criteria exist for the estimation of the number K of clusters in networks but, again, both of them rely on some approximations. In this paper, we show how an analytical expression can be derived for the integrated complete data log likelihood. We then propose an inference algorithm to maximize this exact quantity. This strategy enables the clustering of nodes as well as the estimation of the number clusters to be performed at the same time and no model selection criterion has to be computed for various values of K. The algorithm we propose has a better computational cost than existing inference techniques for SBM and can be employed to analyze large networks with ten thousand nodes. Using toy and true data sets, we compare our work with other approaches.

blogbd

Adjacency matrix of a blogs network, the rows/columns are sorted by cluster number
with clusters found by the greedy ICL algorithm. The cluster boundaries are depicted with white
lines.