Eu posso muito bem estar fazendo algo errado aqui, mas:

Se eu importar algum shapefile para um banco de dados PostGIS usando shp2pgsql , primeiro preciso descobrir o SRID / EPSG desse shapefile. Eu acho que este é, no mínimo, um processo de duas etapas. Primeiro, eu consulto o shapefile assim:

>ogrinfo -al -so someshapefile.shp

que retorna as informações de projeção de texto conhecido (wkt), mas é um pouco detalhado e um pouco opaco [para mim]. 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"]]

Normalmente, executo as informações do wkt por meio de uma ferramenta de conversão como o Prj2EPSG para encontrar o EPSG / SRID.

Neste ponto, eu posso importar o shapefile usando:

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

Note, eu especifico o SRID com a -sbandeira.

Se eu executar o shp2pgsql sem especificar o SRID, nenhuma projeção será definida e acho que a coluna geom precisa ser atualizada manualmente para incluir uma projeção.

Como alternativa, posso pular a pesquisa e usar ogr2ogr :

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

que aparentemente define bem a projeção, presumivelmente extraindo-a automaticamente do shapefile / prj de origem.

Questão

Então, qual é a desvantagem de usar ogr2ogr? De fato, existe um sinalizador para que o shp2pgsql extraia automaticamente e defina a projeção correta também? Se não, por que não?

Termo aditivo

Existe uma análise comparativa interessante, talvez um pouco datada, do uso de ogr2ogr vs shp2pgsql disponível em naturalgis.pt . Isso demonstra, para os dados de amostra específicos, que o ogr2ogr apresenta um desempenho significativamente melhor em conjuntos de dados pequenos , mas que o shp2pgsql apresenta um desempenho um pouco melhor em conjuntos de dados maiores .

Eu não acho que isso fornece uma resposta definitiva. As bases de código podem ter evoluído, melhorando o desempenho de cada um. Eles testaram apenas um conjunto muito pequeno de dados de amostra. O conjunto de dados "grande" representativo não é realmente tão grande. Além disso, está discutindo principalmente questões de desempenho, o que certamente afeta a usabilidade, mas a pergunta original está mais interessada nos requisitos de entrada do usuário relacionados à usabilidade.

Sem falar com os desenvolvedores do shp2pgsql, minha resposta é baseada em opiniões, mas pelo menos o shp2pgsql é muito mais fácil sem a detecção automática da projeção. A parte principal do código-fonte é de cerca de 1800 linhas http://postgis.net/docs/doxygen/2.2/d8/da3/shp2pgsql-core_8c_source.html e faz o que é essencial: converte geometrias e atributos de shapefiles em PostGIS.

Nas fontes GDAL, o código que cuida apenas da interpretação dos arquivos .prj da ESRI é de 2700 linhas https://github.com/OSGeo/gdal/blob/master/gdal/ogr/ogr_srs_esri.cpp .

Prós e contras:

Para os usuários, as principais vantagens do shp2pgsql são:

• vem com PostGIS
• o uso também está documentado em outra documentação do PostGIS http://postgis.net/docs/manual-2.4/using_postgis_dbmanagement.html#shp2pgsql_usage
• shp2pgsql também possui uma interface gráfica com o usuário no pgAdmin

A principal desvantagem do shp2pgsql é que ele suporta apenas shapefiles.

GDAL e ogr2ogr fornecem as mesmas funcionalidades para shapefiles que shp2pgsql, mas o GDAL pode lidar com dezenas de diferentes formatos vetoriais https://gdal.org/ogr_formats.html e oferece muito mais opções para selecionar e processar dados durante a conversão. No entanto, com GDAL

• O usuário deve instalar o GDAL
• O usuário deve aprender a usar GDAL, especialmente ogr2ogr e as muitas opções do driver PostGIS
• ogr2ogr é um utilitário de linha de comando sem GUI