Archive pour la catégorie ‘GeoHacks’

Nouvelle année, nouvelles données INSEE

Dimanche 4 janvier 2009

Si la nouvelle méthode de recensement de l’INSEE, qui procède désormais par échantillonnage, avait déjà permis d’avoir quelques estimations, l’année 2009 s’ouvre avec la publication des données légales de population pour 2006, qui remplacent donc celles vieillissantes de 1999. Ces données légales sont les seules valeurs officielles concernant la population des communes et des entités administratives d’un niveau supérieur.

Pour fêter ça, et parce que ce sont des données qui nous concernent tous, j’ai réalisé une petite application de cartographie dynamique desdits résultats, qui mérite quelques détails techniques.

La récupération des données.

Un petit script en python récupérant les différente synthèses départementales du site de l’INSEE et en extrayant le contenu utile m’a permis de constituer une table communale actualisé. Une jointure sur une table spatiale issue des données de Geosignal (que je remercie au passage pour le droit d’usage concédé gracieusement) , un petit tour sur les anciennes données INSEE (celles de 1999), et me voici avec une table complète : géométrie, code insee, pop1999 et pop2006. Un petit calcul (var = pop2006/pop1999 – 1), un autre (densite = pop2006 / (area(the_geom)/1000000)) et voilà deux autres colonnes, la variation de population communale entre 1999 et 2006, et la densité de chacune des communes en 2006.

La mise en ligne

Divers projets récents m’ont permis de constituer un back-office de publication utilisant GeoDjango, dans lequel j’ai donc injecté les données. Comme il intègre TileCache, les deux couches principales de l’application sont ainsi tuilées et cachées. Les autres (départements, villes, labels) non. Branchons là-dessus un bon client cartographique fait d’OpenLayers et d’ExtJS, et nous pouvons parcourir ce nouveau visage de la population française avec souplesse.

L’accès aux données

Un petit plus du client utilisé, et d’ExtJS en particulier, est sa capacité à accéder aux données attributaires en mode paginé. Un petit clic droit dans la liste des couches (notamment sur Densité ou Variation de population) ouvre un menu contextuel dans lequel l’item ‘Voir les données’ permet de lister l’ensemble des 36580 données communales par bloc de 10. Le tableau utilisé permet également de trier ou filtrer les données, ce qui est toujours pratique pour découvrir qui est la plus dense, qui a eu la plus forte variation…

Copie d'écran de l'application 'Recensement 2006'

Copie d'écran de l'application 'Recensement 2006'

Les petits soucis

Notre organisation administrative est complexe, et chaque année des communes fusionnent, se séparent ou disparaissent. Peu à la fois, mais à raison de 5 à 10 par an, ça peut faire beaucoup. Mon fond cartographique se base sur les communes de 1999, et je n’ai donc pu traiter correctement les données des communes ayant fusionnées avec d’autres (Lomme et Lille, Octeville et Cherbourg). Les variations et densités pour la ville ayant absorbé l’autre sont donc exagérées (la population 2006 de Lille est en fait la population de Lille et de Lomme, mais la carte ne l’affecte qu’à Lille et le calcul la compare avec la population 1999 de Lille seule). Mais sur le nombre, on est à moins de 1 pour 1000…

L’analyse

Contrairement aux résultats de 1999, qui faisaient apparaître une forte augmentation de la population dans les communes de première couronne (au contact de la ville centre), les résultats de 2006 montrent une stabilité de ces zones. Ce sont par contre les communes situées plus loin de la métropole qui voient leur population augmenter fortement. C’est vrai à Toulouse. C’est également visible à une autre échelle en région PACA, ou c’est tout l’arrière-pays qui voit la population augmenter tandis que le littoral stagne. C’est un peu la traduction spatiale et humaine de 7 ans de hausse continue des prix immobiliers, qui a sans cesse poussé les familles à aller plus loin, les rendant dès lors très sensibles au prix du carburant…

Littoralisation et métropolisation sont donc toujours très marquants, mais avec des expressions locales plus diffuses. Regardez Bordeaux aussi.

Intéressant aussi de constater la perte de population qui affecte la Champagne-Ardenne (sans ‘s’ quand c’est la région !). C’est sans doute pourquoi le gouvernement songe à y envoyer les gens de l’INSEE…

Sinon, la France de 2006 compte 27187 communes de moins de 1000 habitants, soit près de 75 %.

Meilleurs voeux à tous !

De la qualité des données accessibles en ligne

Mardi 16 décembre 2008

Gratuites, comme celles de Google, libres, comme celle d’OpenStreeMap, ou payantes, la mise à disposition de données en ligne ne doit pas faire oublier la mesure de leur qualité. C’est une question qui avec l’arrivée de la directive INSPIRE et la probable multiplication des services web cartographiques n’en sera que plus sensible.

Petit exemple vécu récemment : dans le cadre de la mise en oeuvre d’une application web de suivi de véhicules en Algérie, j’ai construit une interface proposant les fonds GoogleMaps.

L\'itinéraire GPS sur fond GoogleMaps

Sauf qu’une fois les trajets intégrés, ils n’étaient absolument pas alignés avec le fond de plan. Donc on vérifie, les données source, les paramètres de projection en Spherical Mercator, la configuration de l’application, l’ellipsoïde de référence… bref, tout ce qu’on peut imaginer être à l’origine de ce qu’on considère comme un problème d’intégration de NOS données.

Puis on affiche le fond satellite :

Le même trajet sur fond satellite

Et on découvre que mise à part une aberration GPS en début de parcours, tout colle parfaitement, et que c’était donc le fond de plan GoogleMaps qui étaient trompeur. D’autant plus trompeur d’ailleurs que la voirie qu’il présente n’a pas grand chose à voir avec ce qu’on voit sur l’image satellite. Nulle trace sur le plan des lacets visibles en haut à gauche par exemple.

Chez OpenStreetMap par contre, le tracé est de bien meilleure qualité…

Fond de plan OSM

mais uniquement quand il existe !

Données fragmentaires, obsolètes, erronées (et je m’en tiens à leur composante graphique, même pas attributaire !), sont autant d’écueils que les utilisateurs de services web cartographiques auront à gérer. Les métadonnées, quand elles existent, donnent des informations utiles (échelle, date…), mais rien ne permet de déterminer la qualité absolue d’une couche de données. Il ne faut donc jamais oublier que la donnée cartographique n’est, à l’instar des sondages, qu’une représentation simplifiée et conceptualisée de la réalité à un moment donné, et jamais une vérité définitive.

Mieux comprendre les tuilages

Mercredi 10 décembre 2008

Voir c’est comprendre, ou du moins mieux comprendre. Cette page réalisée par Klokan Pietr Pridal permet de bien visualiser les grilles de tuilage utilisées en Spherical Mercator, que ce soit en TMS, Google ou QuadTree de Microsoft VirtualEarth.

Chaque pyramide découpe le monde Spherical Mercator selon la même grille, seule change la manière de nommer les tuiles. On remarquera donc l’inversion de l’axe des Y entre le système Google et le TMS (il faut bien faire travailler les développeurs), et le fait que seul le système quadtree puisse s’affranchir de l’information « niveau de zoom » puisqu’il l’intègre naturellement : c’est le nombre de chiffres du numéro de la dalle.

Piétonabilité : de l’analyse raster dans du GoogleMaps

Lundi 13 octobre 2008

Jolie appli que je découvre aujourd’hui : WalkScore a pour but de déterminer un coefficient de « piétonabilité » des rues américaines, cartographié dans GoogleMaps. Mais tout l’intérêt de la chose, c’est qu’on voit apparaître un fond raster analytique, et non une thématisation sur les quartiers par exemple.

Les résultats ont été obtenus en utilisant Google Local Search API sur un maillage de 1,123,855 points différents situés dans les 40 plus grandes villes américaines. Sur chacun des points, un ensemble de divers services a été recherché, pour donner in fine un score. La grille des scores a ensuite été rastérisée. On ne va pas discuter de la méthodologie, c’est une réflexion que WalkScore continue d’affiner. Mais la démarche est enthousiasmante car elle rappelle que les phénomènes spatiaux sont bien plus souvent continus que discrets, et qu’ils ne s’arrêtent pas aux frontières comme on voudrait vous le faire croire.

Quelques tuiles pour l’hiver

Lundi 18 août 2008

L’intérêt de tuiler un jeu de données raster, c’est-à-dire de préparer des imagettes multi-échelles qui seront exploitées nativement dans une application de webmapping n’est plus à démontrer. Dans le cadre du Google Summer of Code 2008, Klokan Petr Pridal vient d’ajouter un nouveau module de ce type aux outils GDAL : gdal2tiles.

Son intérêt principal est de pouvoir exploiter directement une image existante (ECW, TIFF, MrSid, JPEG, JPEG2000 et PNG) sans passer par le relai d’un serveur WMS par exemple comme TileCache. Une arborescence est alors créée répondant aux principes du TMS (Tile Mapping Service). Publiée dans un répertoire web, elle est alors directement exploitable par les client TMS tels qu’OpenLayers.

Mais ce n’est pas tout. Klokan a également inclus des options spécifiques à la création de tuiles pour GoogleMaps (en projection sphérique Mercator donc) ou GoogleEarth (en WGS 84). Qui plus est, l’application génère automatiquement, pour peu qu’on lui demande, des fichiers html pour une mise en ligne immédiate. Simple mais efficace, même dans GoogleEarth qui exploite les SuperOverlays déjà disponible avec TileCache !

Mais ce n’est pas tout ! Klokan a également pensé à ceux d’entre nous qui ne sont jamais arrivés à faire une simple conversion ogr2ogr de Shapefile en MapInfo… Il prépare MapTiler, une interface  graphique pilotant gdal2tiles pour générer ses tuiles en faisant clic clic clic ! Si c’est pas gentil ça !

Pour les autres, voici les quelques options glanées dans la documentation :

gdal2tiles.py [-title "Title"] [-publishurl http://yourserver/dir/]
              [-nogooglemaps] [-noopenlayers] [-nokml]
              [-googlemapskey KEY] [-forcekml] [-v]
               input_file [output_dir]
-title : le titre pour les metadata xml, les pages web et le KML
-publishurl : URL de publication du répertoire contenant les tuiles
-nogooglemaps : pas de génération de page GoogleMaps
-noopenlayers : pas de génération de page OpenLayers
-nokml : pas de génération de KML
-googlemapskey : votre clé GM pour l'utilisation de la page html GoogleMaps
-forcekml : forcer la génération du KML
-v : mode verbeux.
input_file : fichier à traiter
output_dir : répertoire de création des tuiles

Il faut bien noter que gdal2tiles.py est un module Python, et que GDAL doit donc avoir été compilé avec l’option –enable-python.

Source : gdal-dev mailing list