QGIS salvando incorretamente o polígono com CRS personalizado, enquanto o projeta corretamente on-the-fly


8

Estou dividindo um polígono terrestre para mudar a centralização da projeção para o oceano Pacífico. Consigo cortar com êxito o polígono original no meridiano 22 e fica bem quando faço uma reprojeção instantânea com meu CRS personalizado:

Projeção de polígonos OTF

Mas parece estar mudando um pouco ao salvar o polígono com o mesmo CRS:

projeção de polígono salva

Meu CRS está usando esta string proj4: +proj=eqc +lon_0=-158 +datum=WGS84 +units=m +no_defs +lon_wrap=-158

Alguma idéia sobre o que pode estar causando isso?


isso é causado por características que se sobrepõem a -156 + 180 = 24 meridiano leste grau (isto é mais comumente visto com cruzar a antimeridiano 180W, mas é diferente, como você mudou o mapa
Steven Kay

@StevenKay que é realmente um erro de digitação da minha parte: x fixado o meu post original
srha

2
Talvez relacionado: gis.stackexchange.com/questions/70411/… . Usei uma esfera em vez de um elipsóide, um polígono cortado com 0,2 graus de largura e nenhuma +lon_wrapopção.
21717 AndreJ

Respostas:


6

Esses 'artefatos' são um problema bem conhecido e geralmente são o resultado de polígonos cruzando o antimeridiano (180 graus e / w). A solução para isso é geralmente ogr2ogr com a opção wrapdateline.

Mas isso não vai ajudá-lo. No seu caso, você está usando um deslocamento em torno de -156. Isso significa que qualquer recurso que cruze o meridiano 24E (-156 + 180 = 24) está causando problemas.

Para consertar isso, removi uma tira fina de cada lado do 24E.

Comecei com os dados do Natural Earth, parei a projeção (por enquanto) e usei o WGS84.

Para desenhar o meridiano 24E, usei o plugin QuickWKT e adicionei o seguinte como uma nova camada ...

LINESTRING (24 -90,24 90)

Isso desenha uma única linha ao longo do comprimento do meridiano 24E.

Em seguida, digitalizei manualmente uma camada de rascunho de polígono , adicionando dois polígonos, um em cada lado da linha e um hemisfério em tamanho, mas abraçando a linha o mais próximo possível. (Observe a qualidade do desenho de linha aqui ...)

insira a descrição da imagem aqui

Você provavelmente deve fazer isso com o plugin QuickWKT também, para obter mais precisão - envolve mais digitação e eu queria um teste rápido :)

Em seguida, usei o clipe para cortar meu shapefile original na camada com os dois polígonos. Isso corta uma tira fina em torno do meridiano 24E ...

insira a descrição da imagem aqui

finalmente, apliquei a projeção OTF usando seu CRS personalizado - e o resultado fixo.

insira a descrição da imagem aqui


Ah não! Gostaria de ter voltado ao meu computador antes de você fazer todo esse trabalho para mim. Minha sequência de proj4 era, na verdade, em torno de 158; Eu apenas colei o errado em (com 156) depois de fazer algumas experiências.
srha 18/05/19

você verá o mesmo problema com o 158 (eu faço assim mesmo) - basta mudar de 24 para 22. Se você conseguiu que funcionasse sem fazer isso, deixe-me saber como - eu não encontrei o recurso lon_wrap no proj4 até recentemente :) (pense bem, isso pode explicar por que Madagscar parece um pouco compensado ...)
Steven Kay

1
Então, eu fiz todos os passos que você fez (essencialmente) - a tira de polígono WKT em torno de 22; Vetor> Geoprocessamento> Diferença será exibida como minha camada de entrada e a faixa WKT como camada de diferença; Reprojeto OTF. Até esse ponto, tudo parece ótimo. O problema surge depois que eu salvar meu polígono resultante com os mesmos CRS personalizados - o polígono salvo é tudo wonky, mas a um OTF é bom :(
srha

1
obrigado por esclarecer ... acabei de carregar a camada salva do meu projeto (agora descartado) (salvo usando o proj4 personalizado CRS) e o valor lon_wrap não está aparecendo nos metadados da camada. esse pode ser o problema #
Steven Kay

Hmm. Você sabe como consertar isso? Acho a documentação do proj4 um pouco confusa.
srha 18/05/19
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.