Vous utilisez shp2pgsql au lieu de ogr2ogr pour importer un fichier de formes dans PostGIS? [fermé]

8

Je peux très bien faire quelque chose de mal ici, mais:

Si j'importe un fichier de formes dans une base de données PostGIS à l'aide de shp2pgsql , je dois d'abord déterminer le SRID / EPSG de ce fichier de formes. Je pense que c'est, au minimum, un processus en deux étapes. Je demande d'abord le fichier de formes comme ceci:

>ogrinfo -al -so someshapefile.shp

qui renvoie les informations de projection de texte bien connues (wkt), mais est un peu verbeuse et quelque peu opaque [pour moi]. Quelque chose comme:

GEOGCS["NAD83",
DATUM["North_American_Datum_1983",
    SPHEROID["GRS 1980",6378137,298.257222101,
        AUTHORITY["EPSG","7019"]],
    AUTHORITY["EPSG","6269"]],
PRIMEM["Greenwich",0,
    AUTHORITY["EPSG","8901"]],
UNIT["degree",0.01745329251994328,
    AUTHORITY["EPSG","9122"]],
AUTHORITY["EPSG","4269"]]

J'exécute ensuite généralement les informations wkt via un outil de conversion comme Prj2EPSG pour trouver l'EPSG / SRID.

À ce stade, je peux importer le fichier de formes en utilisant:

>shp2pgsql -I -s 4269 someshapefile.shp <schema>.<table> | psql -U <user> -d <dbname> -h <hostaddress> -p 5432

Remarque, je spécifie le SRID avec le -sdrapeau.

Si je lance shp2pgsql sans spécifier le SRID, aucune projection n'est définie et je pense que la colonne geom doit être mise à jour manuellement pour inclure une projection.

Alternativement, je peux ignorer la recherche et utiliser simplement ogr2ogr :

>ogr2ogr -f "PostgreSQL" "PG:host=<hostaddress> user=<user> dbname=<dbname> password=<password>" "C:/shapefile.shp" -nln <schema>.<table>

ce qui, semble-t-il, règle la projection finement, l'extrait vraisemblablement automatiquement du fichier de formes / prj source.

Question

Alors, quel est l'inconvénient d'utiliser ogr2ogr? Existe-t-il en fait un drapeau pour que shp2pgsql extrait automatiquement et règle également la bonne projection? Sinon, pourquoi pas?


Addenda

Il existe une analyse comparative intéressante, peut-être légèrement datée, de l'utilisation d'ogr2ogr vs shp2pgsql disponible sur naturalgis.pt . Il démontre pour leurs échantillons de données particuliers, que ogr2ogr fonctionne beaucoup mieux sur les petits ensembles de données , mais que shp2pgsql fonctionne légèrement mieux sur les grands ensembles de données .

Je ne pense pas que cela fournisse une réponse définitive. Les bases de code peuvent avoir évolué, améliorant les performances de chacun. Ils n'ont testé qu'un très petit ensemble d'exemples de données. Le «grand» ensemble de données représentatif n'est pas vraiment si grand. En outre, il aborde principalement les problèmes de performances, ce qui affecte certainement la convivialité, mais la question d'origine s'intéresse davantage aux exigences d'entrée utilisateur liées à la convivialité.

jac
la source
1
Je ne pense pas avoir jamais eu de fichier de formes où j'ai douté du SRS. J'ai certainement eu des fichiers de formes qui m'ont forcé à remettre en question ma volonté de vivre à tant d'autres niveaux, mais la question de savoir quel est le meilleur environnement pour analyser un format obsolète limité à 2 Go, qui permet toutes sortes de géométries auto-entrecroisées, etc. beaucoup d'autres horreurs n'en font pas partie.
John Powell

Réponses:

4

Sans parler avec les développeurs de shp2pgsql, ma réponse est basée sur l'opinion, mais au moins shp2pgsql est beaucoup plus facile sans détection automatique de la projection. La partie principale du code source est d'environ 1800 lignes http://postgis.net/docs/doxygen/2.2/d8/da3/shp2pgsql-core_8c_source.html et il fait l'essentiel: convertit les géométries et les attributs des fichiers de formes en PostGIS.

Dans les sources GDAL, le code qui ne s'occupe que de l'interprétation des fichiers ESRI .prj est de 2 700 lignes https://github.com/OSGeo/gdal/blob/master/gdal/ogr/ogr_srs_esri.cpp .

Avantages et inconvénients:

Pour les utilisateurs, les principaux avantages de shp2pgsql sont:

Le principal inconvénient de shp2pgsql est qu'il ne prend en charge que les fichiers de formes.

GDAL et ogr2ogr donnent les mêmes fonctionnalités pour les fichiers de formes que shp2pgsql mais GDAL peut gérer des dizaines de formats vectoriels différents https://gdal.org/ogr_formats.html et il offre beaucoup plus d'options pour sélectionner et traiter les données pendant la conversion. Cependant, avec GDAL

  • L'utilisateur doit installer GDAL
  • L'utilisateur doit apprendre à utiliser GDAL, en particulier ogr2ogr et les nombreuses options du pilote PostGIS
  • ogr2ogr est un utilitaire de ligne de commande sans interface graphique
user30184
la source
Vous avez un point valide - la logique d'analyse du fichier .prj est compliquée et comporte des cas d'angle non traités. Ma question, cependant, est principalement liée à l' utilisabilité des outils.
jac le
ogr2ogr et gdal sont des maux nécessaires, mais votre point est bon - ils ne sont pas évidents et ont une courbe d'apprentissage. shp2pgsql fait ce qu'il dit sur la boîte.
John Powell