J’ai pu apercevoir quelques graphiques ici ou là mais rien de disponible en ligne. J’ai réalisé mes propres tests dont voici les résultats (ils confirment les tendances décrites dans les billets précédents).

Les tests ont été réalisés sur des opérations d’ajout de métadonnées avec une dizaine d’utilisateurs en parallèle. L’ajout consiste en l’envoi d’un fichier, son insertion dans la base de données et son indexation (non spatiale et spatiale).

10 ou 10000 ?

Tout d’abord, si l’objectif est de mettre en place un catalogue avec plus de 10000 métadonnées, ne pas utiliser la version 2.4. En effet, depuis la version 2.5, les performances d’insertion et mise à jour des métadonnées sont bien meilleures. Les graphiques ci-dessous illustrent les gains obtenus dans ce domaine entre les versions 2.4.3 et 2.6.0.

En 55 min, 30 000 fiches insérées dans la version 2.6.0 contre 18 000 en 255 minutes pour la version 2.4.3. Par ailleurs, il est important de noter qu’avec la version 2.6.0 le temps d’insertion ne se dégrade presque plus lorsque le nombre de métadonnées dans le catalogue augmente. Ceci est un point critique lorsqu’il est envisagé de moissonner la terre entière !

PostgreSQL+Shapefile ou PostGIS ?

Prenons un jeu de données réel composé de 3700 fiches issues d’un géoportail national voisin comprenant de nombreuses étendues géographiques de type emprise simple ou polygone englobant afin de voir l’impact de l’utilisation d’un index spatial de type ESRI Shapefile ou PostGIS.

Un petit avantage pour PostGIS dans ce cas.

Il serait intéressant d’analyser la partie recherche, une fois toutes ces fiches saisies et insérées !

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 :

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.

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.

Ce référentiel utilise un nouveau namespace, c’est-à-dire qu’il se situe au même niveau que celui de l’EPSG. Cela pose quelques problèmes, puisque MapServer par exemple ne prévoit que de rechercher le namespace epsg. Une projection définie par « +init=IGNF:LAMBE » ne sera donc pas interprétée comme du Lambert Etendu, mais fera planter MapServer. Pour pallier ce manque, et en attendant qu’une prochaine version de MapServer intègre cette modification, une version custom IGN de MapServer 5.0.0. est disponible. On peut lui parler en IGNF sans la vexer. Comme me le rappelait Gilles Martinoty, chef de projet Lambert 93 à l’IGN, ce nouveau registre garantit traçabilité et fiabilité des paramètres puisqu’il est fourni par le Service de Géodésie de l’IGN, responsable des systèmes géodésiques français.

En outre, ce registre comporte aussi la description des projections utilisées par le Géoportail, ce qui peut permettre d’intégrer ses propres couches ainsi reprojetées à une application utilisant l’API Géoportail (en 800 x 600, et à raison de 10000 tuiles par jour et par clé selon les nouvelles conditions d’utilisation). On y apprend que la projection utilisée est une projection équirectangulaire, dont seul le parallèle de référence change pour les diverses zones représentées (Métropole, DOM, TOM et autres…)

A noter que le registre IGNF existe aussi pour PostGIS (469 injectées dans la table spatial_ref_sys) et pour QGis. On dit merci qui ?

via Planet Geospatial

• Si les données sources ne sont pas en shapefile, mais en .TAB par exemple, préférer ogr2ogr à un passage par un shapefile intermédiaire, car cela permettra de préserver les noms de champs longs, systématiquement tronqués à 10 caractères lors d’un passage en DBF (avec un shapefile donc).
• Si l’identifiant de la table à créer DOIT être « gid » pour correspondre à des requêtes existantes, prendre shp2pgsql car la modification du nom de la clé primaire par défaut dans ogr (nommée ogc_fid) passe par des variables d’environnement de postgresql, pas très pratiques.
• pour transcrire directement des données 3D en 2D, utiliser ogr2ogr avec l’option -lco DIM=2
• pour spécifier la projection de la nouvelle table, les deux logiciels sont équivalents, mais pour PROJETER les données à la volée (les stocker dans un autre système de projection que celui du fichier source) ogr2ogr est la seule solution.
• chacun propose aussi les options nécessaires pour le mode de « création » : création réelle, remplacement, mise à jour. A noter que l’option spécifique d’ogr pour postgresql (-lco OVERWRITE=yes) ne fonctionne pas sans l’option générale -overwrite
• Seul shp2pgsql permet de spécifier facilement l’encodage de la donnée source (ASCII par défaut) à l’aide de l’option -W. Ogr utilise la variable d’environnement PG_CLIENT_ENCODING, et c’est donc par là qu’il faut passer pour intégrer des données particulières. Ca marche mais c’est moins pratique.
• Création d’un index spatial : seul shp2pgsql propose cette option. L’utilisation d’ogr doit donc être suivie d’une requête SQL spécifique pour le créer. A ne pas négliger car la présence d’un tel index optimise toutes les requêtes exploitant le champ géométrique.
• Conversion des champs : par défaut, ogr2ogr crée des champs à l’identique du DBF. Donc si vous aviez un champ type caractère de taille 10, il en résultera un CHAR(10) dans Postgresql, rempli de blancs quand le contenu du champ n’est pas suffisamment long. Ca peut créer de mauvaises surprises lors de requêtes… Donc ajouter l’option -lco PRECISION=NO si c’est le cas.

Pour compléter ce bref comparatif, voici des requêtes types pour chacun des logiciels :

shp2pgsql -s 27572 -c -D -i -I nom_du_shape nom_de_la_table > nom_fichier.sql

A noter que shp2pgsql est en fait un transcripteur de shape en SQL. Il faut donc ensuite faire lire ce résultat à postgresql : psql -d nom_de_la_base -f nom_fichier.sql
Sous linux, les deux commandes peuvent se piper facilement : shp2pgsql -s 27572 -c -D -i -I nom_du_shape nom_de_la_table | psql -d nom_de_la_base
Dans cet exemple, il est demandé de créer une table en Lambert II étendu (SRID 27572), en mode création (option -c), en mode COPY (-D) nettement plus rapide que des INSERT, mais qui pose parfois problème avec des caractères spéciaux, de mettre les champs de type integer en mode INT4 (option -i, à ne pas utiliser si les données dépassent cette capacité), et enfin de créer un index spatial (-I) ce qui s’avère souvent indispensable. A noter aussi une option intéressante (-S) pour intégrer les géométries en mode simple et non multiple (pour un shapefile contenant des lignes, un table de MULTILINESTRING est sinon créée par défaut). Il faut cependant s’assurer auparavant que tous les objets du shapefile ont bien des géométries simples.

La syntaxe d’ogr2ogr est un peu plus verbeuse, rebutante même de prime abord. L’équivalent de la requête précédente donne en effet :

ogr2ogr -overwrite -a_srs « EPSG:27572″ -f PostgreSQL PG: »host=serveur user=postgres password=postgres dbname=nom_base » fichier_shape.shp -lco LAUNDER=yes -lco DIM=2 -lco GEOMETRY_NAME=the_geom -lco PRECISION=NO -nln nom_table
dans laquelle il est spécifié :
-overwrite pour remplacer la table si elle existe
-a_srs « EPSG:27572″ : pour indiquer que la table est en Lambert II étendu
-f PostgreSQL + chaîne de connexion pour spécifier la base cible
ensuite viennent les options spécifiques à l’exportation vers postgreSQL :
-lco LAUNDER=yes : permet de corriger les noms des champs pour les rendre compatibles avec postgresql sans utilisation de guillemets dans les requêtes
-lco DIM=2 : nombre de dimensions (x,y,z,m, donc 4 maximum pour un shapefile. Mais ogr ne gère que les trois premières). En spécifiant 2 on contraint la table cible à être en 2D.
-lco GEOMETRY_NAME = the_geom : indique le nom à donner à la colonne géométrique
-lco PRECISION=NO pour avoir des VARCHAR plutôt que des CHAR dans la table cible
-nln nom_table: option New Layer Name (nln) pour spécifier le nom à donner à la table cible, si celui-ci est différent du nom du fichier shape.

Les valeurs par défaut des deux logiciels (pour le nom du champ géométrique par exemple : the_geom dans shp2pgsql, wkb_geometry dans ogr2ogr) impose la plus grande vigilance dans leur manipulation conjointe pour alimenter une base de données. Sans oublier de faire suivre tout import ogr par la création d’un index spatial sur la nouvelle table.