neogeo

Quand on veut intégrer un jeu de données à PostGis, on peut soit utiliser le module de conversion de shape intégré à postgis (shp2pgsql), soit passer par l’excellent utilitaire ogr2ogr qui fait partie de GDAL. Si chacun des deux logiciels génère correctement les tables demandées, on peut privilégier l’un ou l’autre en fonction du contexte d’utilisation :

• 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.

Depuis hier, le géoportail s’est enrichi de nouvelles fonctionnalités liées à l’affichage 3D. D’une part les fonds de cartes peuvent se draper sur le relief, ce qui permet de réaliser de superbes itinéraires de randonnée, d’autre part le bâti est désormais visualisable en 3D, sur toute la France. Ce ne sont encore que des volumes colorés, les façades et les toits (dans les villes uniquement) étant prévus pour 2008.

Après avoir subi bien des critiques, surtout liées à un lancement un peu hâtif, mais il fallait bien rattraper la concurrence, le Geoportail arrive à maturité et peut désormais être considéré comme le meilleur explorateur du territoire français. Meilleur que GoogleEarth ? Pour moi oui. Google Earth est doté d’images exceptionnelles sur certaines parties du territoire, mais d’autres qui sont exécrables. Le Géoportail a une homogénéité et une qualité de la donnée qui seules peuvent en faire un outil de référence. La possibilité de combiner cartes au 25000e, relief et bâtiments est unique, et il faut le saluer.

Reste que le GeoPortail doit encore s’ouvrir. S’ouvrir à Mac et Linux pour la visualisation 3D d’une part (pour 2008 aussi apparemment), s’ouvrir aux autres sources de données issues des services de l’Etat (on pense bien sûr à Cartorisque) mais surtout s’ouvrir côté API pour permettre la création de mash-ups, la personnalisation, l’enrichissement du contenu, tout ce qui a fait le succès de Google.

Sean Gillies n’est pas un plaisantin. Quand il s’attaque à un sujet, ce n’est pas pour faire un truc qui clignote en vous donnant l’heure. Alors quand il s’est penché sur l’implémentation d’OGR en Python, qu’il trouvait médiocre dans sa version native, il a déjà réfléchi plusieurs jours, savoir s’il vallait mieux utiliser CTypes ou Cython pour lier la librairie C native. Le genre de sujet qu’on lui laisse avec soulagement. Mais quand il teste l’ami Sean, il ne se contente pas de dire “Ctypes sucks dude…”, il sort des statistiques :

Refinery (with ctypes): 4972288.61 usec/pass

Ogre (Cython/Pyrex) : 682301.81 usec/pass

ogr.py (old-school bindings) : 9183181.72 usec/pass

Le coup du old-school bindings en a énervé quelques-uns, qui ont fait remarquer qu’il avait utilisé une vieille version d’OGR. Trop facile ! Mais avec la nouvelle, même si celle-ci est 15 fois plus rapide que la précédente (bravo Howard), Cython garde le dessus :

Refinery (with ctypes)
4994133.40 usec/pass

Ogre (Cython/Pyrex)
593522.91 usec/pass

ogr.py (next generation bindings)
594103.50 usec/pass

De cette implémentation efficace avec Cython, Sean a fait un premier prototype, WordMill. Quelques exemples permettent de se rendre compte de la souplesse du programme. La définition d’un workspace (répertoire de données) suffit à permettre l’accès à toutes les sources de données supportées par OGR qui s’y trouvent, et de parcourir ainsi les fichiers et leur contenu de manière transparente quant à leur format, sans appel à un driver particulier et à travers des structures simples. On peut ainsi accéder aux données, les interroger, les filtrer très efficacement. De la belle ouvrage, doublée d’une installation simplissime. Chapeau Sean !

Timeline est un widget Ajax permettant de générer facilement des frises chronologiques à partir d’un flux XML. Petit exemple ci-dessous :

Traduction française de la doc ici

Depuis ce matin sur les étals du geoweb frétille un nouveau specimen dénommé MapFish. Avec pour emblème une magnifique croquette de poisson pané (!) c’est sous ce nom que CartoWeb4, présenté en septembre au FOSS4G, se présente désormais, Cartoweb restant le nom de la branche 3, toujours maintenue depuis la sortie de la version 3.4 fin septembre.

Egalement sponsorisé par CampToCamp, il est vrai que MapFish n’a pas grand’chose à voir technologiquement avec Cartoweb, même si la finalité reste la mise en oeuvre rapide d’applications cartographiques. De fait, MapFish se veut être le chaînon manquant entre la qualité d’un client carto comme OpenLayers et la puissance de traitement qui fait une vraie application de cartographie en ligne. Ceci se fait en deux temps :

- d’une part un client web qui s’appuie sur OpenLayers tout en y juxtaposant des widgets graphiques issus du fascinant framework javascript extjs. On peut ainsi avoir une légende un peu plus raffinée que la simple liste des couches d’OpenLayers, même si le composant à encore des progrès à réaliser (distinction des types de géométries dans les cartouches par exemple). Parmi les widgets on trouve encore un controle de zooms prédéfinis, ou un outil de recherche. Plus complexe, un composant geostatistique permet de réaliser des discrétisations à la volée à partir d’un flux GeoJSON. Ou encore de réaliser des calculs d’itinéraires en se basant sur les fonctions PgRouting de PostGIS développée conjointement par CampToCamp et Orkney. Voilà pour la partie cliente.

- d’autre part, une architecture serveur basée sur le framework python Pylons qui implémente des modules nécessaires au bon fonctionnement des widgets clients, ainsi que le reste de l’application web si nécessaire.

La version présentée aujourd’hui, et annoncée sur la liste openlayers-dev, est une alpha-release. Certes cela se voit, et le récent remplacement du framework js Dojo par Extjs a laissé quelques traces. Mais comment ne pas saluer une initiative qui :

- rappelle qu’une application cartographique sur le web ce n’est pas qu’un tuilage rapide, c’est aussi des données, l’accès à leurs attributs et à la modification de leur représentation.
- s’appuie sur des bibliothèques existantes qui ont fait leurs preuves dans leur domaine (OL, extJs, Pylons), sans chercher à réinventer la roue. C’est du KISS très DRY !
- s’ingénie à fédérer les énergies, non pas en proposant un environnement complet et fermé, mais plutôt une démarche, une dynamique et une boîte à outils.

Voici donc un petit poisson qui a toutes ses chances de devenir grand.