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.

shp2pgsql vs ogr2ogr
Étiqueté avec :    

7 pesnées sur “shp2pgsql vs ogr2ogr

  • 11 avril 2008 à 17:31
    Permalien

    1/ Seul shp2psql ajoute une ligne correspondant à la couche ajouté dans la table public.geometry_columns.

    2/ Seul shp2psql permet de modifier le sql crée (par exemple en augmentant le nbr de lettres dans un varchar) avant son exécution.

    3/ Ce que je fais: préparer le shp avec ogr2ogr (reproj, recut) puis l’insérer via shp2psql

    4/ ogr2ogr travail avec plein de format (http://www.gdal.org/ogr/ogr_formats.html) : super utile

    Répondre
  • 31 mai 2009 à 11:11
    Permalien

    Comparaison intéressante. Quelques éléments supplémentaires et réactions :

    1/ Depuis la rédaction de ce billet, la création des index spatiaux est désormais disponible dans GDAL 1.6.0, et activée par défaut. Ce comportement est contrôlable par l’option -lco SPATIAL_INDEX=YES/NO

    2/ A l’instar de shp2pgsql, le driver PostgreSQL dispose d’une option pour utiliser le mode COPY plutôt qu’INSERT. Il faut définir la variable d’environnement PG_USE_COPY=YES. Par ex ogr2ogr –config PG_USE_COPY YES « PG: » source.shp

    3/ Concernant le commentaire 1/ de syltao, le driver PostgreSQL crée bien une entrée pour la nouvelle couche dans la table geometry_columns, mais à condition que Postgis soit bien installé au préalable dans la base de données destination.

    Toutes les infos sur : http://gdal.org/ogr/drv_pg.html ou en français grâce au superbe travail de traduction d’Y. Jacolin : http://softlibre.gloobe.org/doku.php/gdal_ogr/couteau_suisse/ogr_postgresql

    Répondre
    • 2 juin 2009 à 9:23
      Permalien

      En effet, et c’est tout à l’honneur de l’équipe de développement de GDAL que de sans cesse améliorer cet outil. Il faudrait un billet par mois pour suivre le rythme !

      Répondre
    • 15 mai 2010 à 1:38
      Permalien

      Je le note ! Merci pour cette information Even.

      Guillaume

      Répondre
  • Ping : Manuel ogr2ogr | My Blog Notes

  • Ping : My Blog Notes

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.