Bien podría estar haciendo algo mal aquí, pero:
Si importo algún shapefile a una base de datos PostGIS usando shp2pgsql , primero tengo que averiguar el SRID / EPSG de ese shapefile. Creo que este es, como mínimo, un proceso de dos pasos. Primero consulto el archivo de forma así:
>ogrinfo -al -so someshapefile.shpque devuelve la información de proyección de texto (wkt) conocida, pero es un poco detallado y algo opaco [para mí]. Algo como:
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"]]Luego, normalmente ejecuto la información de wkt a través de una herramienta de conversión como Prj2EPSG para encontrar el EPSG / SRID.
En este punto, puedo importar el archivo de forma usando:
>shp2pgsql -I -s 4269 someshapefile.shp <schema>.<table> | psql -U <user> -d <dbname> -h <hostaddress> -p 5432Nota, especifico el SRID con la -sbandera.
Si ejecuto shp2pgsql sin especificar el SRID, no se establece ninguna proyección y creo que la columna geom debe actualizarse manualmente para incluir una proyección.
Alternativamente, puedo omitir la búsqueda y simplemente usar ogr2ogr :
>ogr2ogr -f "PostgreSQL" "PG:host=<hostaddress> user=<user> dbname=<dbname> password=<password>" "C:/shapefile.shp" -nln <schema>.<table>que aparentemente establece bien la proyección, presumiblemente extrayéndola automáticamente desde el archivo de forma / prj fuente.
Pregunta
Entonces, ¿cuál es la desventaja de usar ogr2ogr? ¿De hecho hay una bandera para que shp2pgsql extraiga automáticamente y establezca la proyección correcta también? ¿Si no, porque no?
Apéndice
Hay un análisis comparativo interesante, quizás algo anticuado, del uso de ogr2ogr vs shp2pgsql disponible en naturalgis.pt . Demuestra, para sus datos de muestra particulares, que ogr2ogr funciona significativamente mejor en conjuntos de datos pequeños , pero que shp2pgsql funciona ligeramente mejor en conjuntos de datos más grandes .
No creo que esto proporcione una respuesta definitiva. Las bases de código pueden haber evolucionado, mejorando el rendimiento de cada uno. Solo han probado un conjunto muy pequeño de datos de muestra. El conjunto de datos representativo "grande" no es realmente tan grande. Además, se trata principalmente de cuestiones de rendimiento, que ciertamente afectan la usabilidad, pero la pregunta original está más interesada en los requisitos de entrada del usuario relacionados con la usabilidad.
Respuestas:
Sin hablar con los desarrolladores de shp2pgsql, mi respuesta está basada en una opinión, pero al menos shp2pgsql es mucho más fácil sin la detección automática de la proyección. La parte principal del código fuente es aproximadamente 1800 líneas http://postgis.net/docs/doxygen/2.2/d8/da3/shp2pgsql-core_8c_source.html y hace lo que es esencial: convierte las geometrías y los atributos de los archivos de forma en PostGIS.
En las fuentes de GDAL, el código que solo se encarga de interpretar los archivos .prj de ESRI es 2700 líneas https://github.com/OSGeo/gdal/blob/master/gdal/ogr/ogr_srs_esri.cpp .
Pros y contras:
Para los usuarios, las principales ventajas de shp2pgsql son:
La principal desventaja de shp2pgsql es que solo admite archivos de forma.
GDAL y ogr2ogr ofrecen las mismas funcionalidades para shapefiles que shp2pgsql, pero GDAL puede manejar decenas de formatos vectoriales diferentes https://gdal.org/ogr_formats.html y ofrece muchas más opciones para seleccionar y procesar datos durante la conversión. Sin embargo, con GDAL
fuente