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 -s
drapeau.
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é.