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.shpqui 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 5432Remarque, 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é.
Réponses:
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
la source