Archive pour la catégorie ‘GeoHacks’

Fresh meat

Samedi 25 avril 2009

Deux sorties dignes d’intérêt ces derniers jours : OpenJump 1.3 et MapServer 5.4.

Concernant le premier, on note l’arrivée de nouvelles méthodes de discrétisation (moyenne, seuils naturels et Jenks notamment) et d’informations statistiques sur les couches (min, max, moyenne…), ainsi que de nouvelles fonctions d’édition des géométries (auto-complétion des polygones sur tracé existant, simplification de polygones sans incohérence, double fenêtrage synchrone…) qui en font un outil de choix pour tout ce qui touche à la manipulation des données.

MapServer voit quant à lui intégrées les améliorations promises par le Toronto Code Sprint. J’ai fait quelques tests habituels sur des extraits de larges couches PostGIS et Shapefile, et les résultats sont assez troublants. Voici un comparatif avec la version 5.2 pour la génération d’une image de 600 x 600 pixels comprenant deux couches, communes et ROUTE250 sur une zone couvrant à peu près la Gironde :

image générée avec le driver AGG

5.2 5.4
Postgis GIF 0.142 0.159
PNG 0.388 0.386
AGG 0.920 0.707
Shapefile GIF 0.101 0.101
PNG 0.297 0.318
AGG 0.920 0.842
SHP + QIX GIF 0.058 0.060
PNG 0.315 0.284
AGG 0.834 0.606

Il y a à mon avis quelques informations utiles à tirer de ces résultats, qui n’ont pas vocation à présenter des index de performance pure, mais bien à comparer les deux versions dans des situations analogues. Considérons le format GIF comme celui de référence car impactant le moins de temps final de création de l’image.

Premièrement, on note une perte de performances légère (moins de 10 %) entre la version 5.2 et la nouvelle version 5.4 en GIF. Paul Ramsey m’a expliqué que c’est dû au passage à un curseur texte pour parcourir la base de données en lieu et place du précédent curseur binaire, plus performant certes, mais beaucoup plus difficile à maintenir et à utiliser dans le code car devant être manipulé au sein de transactions (et je veux bien le croire…).

Deuxièmement, on note toujours l’avantage significatif du shapefile, a fortiori quand il est indexé. Les modifications indiquées ci-dessus portent le ratio à 1.5 avec un Shapefile standard et à plus de 2 avec un fichier .qix. On peut en conclure que pour obtenir les meilleures performances, c’est cette association SHP + QIX + GIF qu’il faut choisir.

Cependant le rapport s’inverse avec les autres formats, comme si le nouvel handicap de l’accès à Postgis était compensé par une meilleure prise en charge du PNG et de l’AGG/PNG. C’est avec ce dernier choix, l’anticrénelage AGG, que l’amélioration est la plus significative, preuve s’il en fallait que Thomas Bonfort (créateur et mainteneur de l’intégration AGG dans MapServer) n’aura pas fait le déplacement à Toronto pour rien. Mais ce que je ne comprends pas, c’est qu’une image PNG ou AGG semble mieux bénéficier des données indexées (Postgis ou qix) que d’un simple shapefile. Thomas, si tu lis ces lignes…
In fine, 20 % de mieux pour le couple le plus sexy (PostGIS + AGG), c’est une vraie bonne nouvelle.

SAO : Saisie assistée par OpenLayers

Jeudi 12 mars 2009

Deux nouveaux contrôles vont faire leur apparition dans OpenLayers 2.8 (ici pour la traduction française, à la grammaire près). Il s’agit d’outils d’aide à la saisie, bien utiles pour faciliter le travail et augmenter sa qualité géométrique.

Un outil de snapping (accrochage aux objets existants) avec une belle granularité des options puisqu’il propose l’accrochage aux noeuds, simples sommets et même bordures, chacune étant complètement configurable indépendamment des autres (activation, tolérance).

Un outil de découpage (split) qui permet de décomposer des géométries existantes à partir d’un nouveau tracé. C’est par exemple utile lors de la création de réseaux linéaires, une nouvelle ligne découpant automatiquement celles qu’elle coupe aux intersections, de manière à obtenir un réseau non pas encore topologique (il faudra séparer noeuds et arcs pour cela) mais bien structuré. Ca parait plus simple que le snapping, mais c’est plus délicat que ça en a l’air, car l’utilisation de cet outil impacte des géométries existantes à la différence du premier qui ne faisait que les utiliser. Un objet linéaire disposant d’un id et d’un attribut longueur par exemple va se retrouver segmenté en deux parties distinctes, dont il faudra donc corriger les attributs (nouveaux ids, recalcul des longueurs…). Fort heureusement l’outil de découpage a été bien conçu puisqu’il intègre un événement aftersplit qui permet de récupérer les objets venant d’être recomposés. Charge au développeur d’implémenter ce dont il a besoin à ce niveau.

Les objets à découper peuvent également être filtrés en fonction d’un attribut (afin, par exemple, de ne pas découper les autoroutes quand on trace des départementales)

Enfin, les deux contrôles peuvent être activés conjointement, et permettent d’interagir (en découpe ou accroche) avec d’autres couches que celles utilisées pour la saisie.

Au-delà de la prouesse technique, j’avoue que je suis surtout séduit par le professionnalisme de l’approche « métier ».  Sans doute que le sponsor de ces développements, SWECO, spécialisé dans le génie civil et le BTP n’y est pas étranger ! Un seul défaut à mon sens, l’absence de curseur de contrôle du positionnement en tout début de saisie, qui fait que le premier point est placé sans savoir si l’accrochage est effectif ou pas. Et si la taille de celui-ci, qui serait alors un cercle, pouvait reprendre la tolérance, on toucherait au nirvana !

Plus prosaïquement, on se rapproche lentement de solutions full-web de saisie cartographique. Quelques contrôles de topologie effectués sur le serveur (au hasard avec… GeoDjango !) peuvent venir améliorer encore le résultat sans trop d’efforts (absence d’intersection entre les polygones, validité des géométries…). Reste que la manipulation d’objets vectoriels dans un navigateur a une limite liée à la capacité de ce même navigateur. Au-delà d’un certain nombre de points (sommets, noeuds…), l’application se fige et devient inutilisable. Mais cette limite est sans cesse repoussée par l’améliration des navigateurs et la puissance des machines. Donc oui, ça devient envisageable, sans être trivial.

GeoDjango, LE framework cartographique.

Samedi 10 janvier 2009

J’en ai parlé dans le post précédent, mais pas de manière suffisamment détaillée pour satisfaire les curieux qui m’ont rappelé à l’ordre et soumis des questions diverses. Donc je vais essayer de me rattraper…

Qu’est-ce que GeoDjango ?

C’est une extension de Django (ça existe même en français) destinée à gérer les données géographique. OK, mais on n’avance pas là. Qu’est-ce que Django ? Un framework web en Python sous licence OpenSource BSD qui permet de structurer un site web au travers d’une structure Modele – Vue – Template très rapidement. Les modèles sont les tables de votre BD, mais en mode objet; les vues sont les actions et les manipulations diverses que vous voulez effectuer, et les templates sont des modèles de mise en page HTML destinés à présenter les résultats des vues. De plus, Django génère automatiquement un module d’administration des Modèles (des tables donc), qui permet facilement de CRUDer (lire, retrouver, mettre à jour, supprimer) le contenu de votre SI. Un peu comme PhpMyAdmin, mais en mieux !

A ceci, GeoDjango ajoute donc la dimension spatiale, tout comme PostGIS ajoute la dimension spatiale à PostgreSQL. Cela peut fonctionner avec PostgreSQL, MySQL ou Oracle, mais pour ces deux derniers toutes les fonctions ne sont pas encore intégrées (voir la table de compatibilité). Vous obtenez alors des tables spatiales référencées en tant que modèles, et manipuler les objets géométriques (intersection, union, extent, aire…). Ceci grâce au portage dans le code de GeoDjango des librairies bien connues GDAL et GEOS.

Depuis août 2008, GeoDjango fait partie intégrante de Django, tout en gardant sa propre doc et son wiki.

KiCéKiLaFé ?

Justin Bronn, qui va bientôt passer ses examens pour devenir District Attorney (procureur…). A l’occasion de la mise en place de son application Houston Crime Maps, il a choisi Django et y a progressivement intégré la dimension spatiale dont il avait besoin.

Et on peut voir ça où ?

Une petite application de démonstration est accessible ici. Elle a été construite par Dane Springmeyer, Josh Livni et  Christopher Schmidt. Vous pouvez utiliser le login/passwd geo/geo pour vous connecter au module d’administration. Surprise, les données géographiques sont éditables grâce à l’intégration d’OpenLayers dans la page et de votre objet en mode vectoriel !

Sinon la présentation faite par Justin Bronn au Forum Texas GIS en octobre 2008 donne aussi quelques liens.

Ok, c’est beau, mais il y a de la doc ?

Oui, aussi. D’abord un tutoriel : http://geodjango.org/docs/tutorial.html#geographic-data

Un kit d’installation : http://geodjango.org/docs/install.html

Les spécificités des modèles GeoDjango (qui surclassent les modèles standard Django)

La DB-API, qui intègre les opérateurs spatiaux.

et plein d’autres trucs (sur GDAL, GEOS…)

et enfin, un groupe de discussion !

et sinon, tu en penses quoi ?

Je ne suis pas forcément très objectif, mais je suis un inconditionnel de Django en général et de GeoDjango en particulier. Ce que j’apprécie le plus est de pouvoir stocker les données géographiques sous PostGIS et de les manipuler ensuite pour les envoyer vers le client en GeoJSON par exemple après les avoir reprojetées ou simplifiées. Le GeoAdmin, et la capacité d’édition de la donnée qu’il apporte, même si elle est imparfaite, est aussi très agréable.

La prise en main n’est pas très difficile. Les tutoriels de Django et GeoDjango sont très accessibles, et la vitesse à laquelle on arrive à des résultats concrets donne vite envie d’aller plus loin.

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.