neogeo

Paul Ramsey, de Refractions Research, profite de la mise à jour du site web consacré à PostGIS pour nous livrer une brève histoire de PostGIS. Intéressant et enrichissant de constater le succès de cette solution phare de l’OpenSource geospatial en si peu de temps. Les prémices du projet datent de mai 2001 (version 0.1 le 31 Mai), mais il faut attendre la version 0.8, début 2004, pour voir intégrées les projections, l’indexation GIST (déjà dans la 0.7) et surtout les fameuses JTS (Java Topology Suite) dans leur version C++ dénommée GEOS, ce qui en fait enfin un SGBD spatial totalement opérationnel. Depuis ? PostGIS est devenue la référence dans le monde des bases de données spatiales, du fait de son coût et de sa formidable interopérabilité. L’industrie SIG ne s’y est pas trompée puisque les “passerelles” vers PostGIS ont fleuri ces dernières années (dans FME, Geoconcept 6, et même ESRI, qui a pourtant son propre SGBD spatial). Belle performance pour un produit de moins de 7 ans d’âge (même pas le temps de faire un bon whisky ça !).

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.

Nul doute que le succès de PostGIS fait des envieux. Ses performances en font même un sérieux challenger aux solutions Oracle, à tel point que des organismes prestigieux le privilégient (voir Oracle, PostGIS et MySQL : éléments de comparaison, via postGIS.fr et surtout l’étude de cas de l’IGN).

Les grands de ce monde se devaient donc de réagir. A la conférence annuelle des utilisateurs des produits ESRI (ESRI International User Conference 2007), Jack Dangermond a ainsi répondu à la question : “Will ESRI support the PostGIS open-source spatial extension for PostgreSQL?” :

- Yes, ESRI will provide our customers with the option of using either the ISO/OGC spatial type or the PostGIS spatial extension.

Comme Paul Ramsey le remarque malicieusement, Jack induit ainsi le doute quant au respect des normes ISO/OGC dans PostGIS, ce qui est habile mais légèrement tendancieux. Plus précisément, si ArcSDE envisage bien une interconnexion postGIS, ce n’est pas forcément sur le format natif de celui-ci, mais le format maison SDEBINARY simplement intégré à postGIS. Ca peut permettre à votre ArcMap d’utiliser des données stockées dans postGIS, mais quel intérêt si ces données, de par leur format spécifique, sont inutilisables hors de la passerelle ArcSDE (dans MapServer par exemple) ? L’interropérabilité en prend un coup.

Dans le même temps, Microsoft, singulièrement à la traîne pour ce qui était des bases de données spatiales, introduit dans SQL Server 2008 (nom de code Katmai) le support complet des données géographiques, pour lequel on annonce déjà une intégration parculièrement poussée avec les produits ESRI (”The spatial database offerings of specific ESRI partners were developed using core, underlying ESRI technology and hence have a high degree of similarity“). Est-ce à dire que SQL Server 2008 va devenir le SGBD “naturel” de la gamme ArcGIS ? Du subtil dénigrement de PostGIS mentionné plus haut et de l’étroite collaboration ESRI-Microsoft autour de SQL Server, on peut raisonnablement le déduire.

On sent surtout la crainte de voir les utilisateurs ArcQuelquechose migrer vers les solutions OpenSource pour le stockage ou la diffusion des données sur le web, tout en conservant leur Arc comme client SIG desktop, pour la manipulation et la visualisation des données. Qui n’a pas son égal en OpenSource, force est de le constater.