Por que o QGIS não está detectando o CRS do arquivo .prj?

Eu tenho um número de grades hexagonais de 1 km que cobrem vários municípios nos Estados Unidos em um banco de dados postgreSQL / postGIS. Cada grade possui o CRS EPSG: 3857 e a camada de condados possui o EPSG: 3857. Ao visualizar as grades com os condados no QGIS, tudo parece ótimo.

Mas ... para compartilhar essas grades com os colegas, tive que exportá-las para shapefiles usando ogr2ogr. Ao visualizá-las no QGIS, cada grade parece aproximada cerca de 20 km, e o QGIS define automaticamente o CRS como EPSG: 3395 (que não é o CRS do projeto).

Quando eu exporto as tabelas postGIS como shapefiles do QGIS , o arquivo .prj é exatamente igual aos shapefiles exportados pelo ogr2ogr , mas as tabelas exportadas postGIS são exibidas corretamente. Percebi que o QGIS cria um arquivo .qpj ao exportar shapefiles do QGIS , então concluí que o QGIS está ignorando o .prj e procurando um .qpj. Por que ele não pode ler o .prj sem um .qpj? Outros shapefiles (como os do censo dos EUA) não possuem um .qpj, mas o QGIS os exibe corretamente.

Eu criei uma solução alternativa salvando um default.qpj e criando um novo .qpj para cada arquivo exportado usando ogr2ogr, mas isso parece confuso e obviamente não reproduzível, pois funciona apenas para o EPSG: 3857.

Nota: Estou usando o QGIS 2.0.1.

EDITAR:

Aqui está o comando ogr2ogr que eu usei:

ogr2ogr -f "ESRI Shapefile" /home/matt/data/hex_grid_1 PG:'dbname=mydb user=matt' hex_grid_1

Conteúdo do .prj:

PROJETOS ["WGS_84_Pseudo_Mercator", GEOGCS ["GCS_WGS_1984", DATUM ["D_WGS_1984", SPHEROID ["WGS_1984", 6378137,298.257223563]], PRIMEM ["Greenwich", 0], UN17 [32] ["Mercator"], PARÂMETRO ["central_meridian", 0], PARÂMETRO ["false_easting", 0], PARÂMETRO ["false_northing", 0], UNIDADE ["Medidor", 1], PARÂMETRO ["standard_parallel_1", 0,0] ]

Conteúdo do .qpj:

PROJETOS ["WGS 84 / Pseudo-Mercator", GEOGCS ["WGS 84", DATUM ["WGS_1984", SPHEROID ["WGS 84", 6378137,298.257223563, AUTORIDADE ["EPSG", "7030"]], AUTORIDADE [" EPSG "," 6326 "]], PRIMEM [" Greenwich ", 0, AUTORIDADE [" EPSG "," 8901 "]], UNIDADE [" diploma ", 0,0174532925199433, AUTORIDADE [" EPSG "," 9122 "]], AUTORIDADE ["EPSG", "4326"]], PROJEÇÃO ["Mercator_1SP"], PARÂMETRO ["central_meridian", 0], PARÂMETRO ["scale_factor", 1], PARÂMETRO ["false_easting", 0], PARÂMETRO ["false_northing" , 0], UNIDADE ["medidor", 1, AUTORIDADE ["EPSG", "9001"]], EIXO ["X", ORIENTE], AXIS ["Y", NORTE], EXTENSÃO ["PROJ4", "+ proj = merc + a = 6378137 + b = 6378137 + lat_ts = 0,0 + lon_0 = 0.0 + x_0 = 0,0 + y_0 = 0 + k = 1,0 + unidades = m + nadgrids = @ null + wktext + no_defs "], AUTORIDADE [" EPSG "," 3857 "]]

EDIT :

O problema foi resolvido convertendo o EPSG: 3857 para EPSG: 2163 em todos os meus scripts. Ainda não tenho certeza de qual é o problema, pois as grades são exibidas corretamente no QGIS quando originalmente carregadas de uma tabela postgreSQL (com EPSG: 3857).

Minha solução alternativa foi bruta como eu pensava, pois meu colega não conseguiu usar o arquivo no ArcGIS, que não leu o .prj ou o .qpj corretamente.

— haff
fonte

Você pode adicionar o comando ogr2ogr?

— alphabetasoup

Você também pode postar o conteúdo dos arquivos .prj e .qpj?

— Mcknedy # 9/16

Pode ser, existem capacidades limitadas em que "projeção WGS84 Web Mercator em um auxiliar Sphere" en.wikipedia.org/wiki/Web_Mercator ..Unlike a elipsoidal Mercator e esférica Mercator, a Web Mercator não é bem conformada devido ao seu uso de elipsoidal coordenadas geográficas dos dados contra uma projeção esférica.

— huckfinn

@ huckfinn Alterei todo o EPSG: 3857 para EPSG: 2163 no meu script e meu problema está resolvido. Ainda não sei ao certo por que isso ocorre, já que todas as grades foram exibidas corretamente quando carregadas das tabelas postgreSQL com EPSG: 3857. Obrigado pela dica.

— haff 9/03/16

A EPSG:3857definição é um truque sujo para obter a projeção que o Google inventou no moderno software GIS. É uma combinação de esfera e elipsóide que não é usada por projeções "normais". Infelizmente, todo software usa outra maneira de adaptá-lo.

O QGIS usa o arquivo .qpj, ARCGIS, o WKT no arquivo .prj e GDAL a definição do proj.4. O arquivo .qpj incorpora a definição proj.4 na definição WKT.

A maneira mais segura de lidar com esses problemas é evitar o Google Mercator. Você pode usar melhor o seu plano estadual local, UTM ou algumas projeções de Lambert ou Albers em todo o continente.

— AndreJ
fonte

Bom saber. Obrigado pela sua resposta. Notei, no entanto, que quando exporto um arquivo de forma com o EPSG 2163 usando ogr2ogr, não há .qpj criado, mas o QGIS ainda o lê corretamente. Portanto, estou assumindo que o QGIS lerá informações de um .prj na ausência de um .qpj. Além disso, as projeções do plano estadual funcionarão muito bem se estiverem operando apenas em um estado, mas meus scripts usam códigos de condados de vários estados, portanto, um plano estadual não seria prático no meu caso.

— haff 10/03/16

O QGIS geralmente funciona bem com o arquivo .prj, mas não com os arquivos projetados do World Merctaor que vêm de outro software. O SRC mais adequado depende sempre do tamanho da área de estudo. O EPSG 2163 deve estar ok para a sua tarefa.

— Andrej