QGIS guarda incorrectamente el polígono con CRS personalizado, mientras lo proyecta correctamente sobre la marcha


8

Estoy dividiendo un polígono terrestre para cambiar el centrado de la proyección al océano Pacífico. Logré cortar con éxito el polígono original en el meridiano 22, y se ve bien cuando hago una reproyección sobre la marcha con mi CRS personalizado:

Proyección poligonal OTF

Pero parece estar cambiando ligeramente al guardar el polígono con el mismo CRS:

proyección de polígono guardada

Mi CRS está utilizando esta cadena proj4: +proj=eqc +lon_0=-158 +datum=WGS84 +units=m +no_defs +lon_wrap=-158

¿Alguna idea de lo que pueda estar causando esto?


esto se debe a que las características se superponen al meridiano -156 + 180 = 24 grados este (esto se ve más comúnmente al cruzar el antimeridiano 180W, pero es diferente a medida que cambiaste el mapa)
Steven Kay

@StevenKay que en realidad es un error de mi parte: x arregló mi publicación original
srha

2
Quizás relacionado: gis.stackexchange.com/questions/70411/… . Usé una esfera en lugar de un elipsoide, un polígono cortado de 0.2 grados de ancho y ninguna +lon_wrapopción.
AndreJ

Respuestas:


6

Estos 'artefactos' son un problema bien conocido, y generalmente son el resultado de polígonos que cruzan el antimeridiano (180 grados e / w). La solución para esto es usualmente ogr2ogr con la opción wrapdateline.

Pero eso no te ayudará. En su caso, está utilizando un desplazamiento de alrededor de -156. Esto significa que cualquier característica que cruce el meridiano 24E (-156 + 180 = 24) le está causando problemas.

Para solucionar esto, eliminé una tira delgada a cada lado de 24E.

Comencé con los datos de Natural Earth y dejé la proyección (por ahora), y solo usé WGS84.

Para dibujar el meridiano 24E, utilicé el complemento QuickWKT y agregué lo siguiente como una nueva capa ...

LINESTRING (24 -90,24 90)

Eso dibuja una sola línea a lo largo del meridiano 24E.

Luego, digitalicé manualmente una capa de rasguño de polígono , agregando dos polígonos, uno a cada lado de la línea y un hemisferio de tamaño, pero abrazando la línea lo más cerca posible. (Tenga en cuenta la calidad del dibujo lineal aquí ...)

ingrese la descripción de la imagen aquí

Probablemente también deberías hacer eso con el complemento QuickWKT, para obtener más precisión: implica más tipeo y quería una prueba rápida :)

Luego, usé clip para recortar mi archivo de forma original a la capa con los dos polígonos. Esto corta una tira delgada alrededor del meridiano 24E ...

ingrese la descripción de la imagen aquí

Finalmente, apliqué la proyección OTF usando su CRS personalizado y el resultado fijo.

ingrese la descripción de la imagen aquí


Ah, oh no! Ojalá hubiera vuelto a mi computadora antes de que hicieras todo este trabajo por mí. Mi cadena proj4 era en realidad alrededor de 158; Acabo de pegar el equivocado (con 156) después de hacer un poco de experimentación.
Srha

verá el mismo problema con 158 (lo hago de todos modos), solo cambie 24 a 22. Si logra que funcione sin hacer esto, hágamelo saber cómo: no había encontrado la función lon_wrap en proj4 hasta hace muy poco :) (ahora que lo pienso, eso podría explicar por qué Madagscar parece ligeramente compensado ...)
Steven Kay

1
Así que hice todos los pasos que hiciste (esencialmente): tira de polígono WKT alrededor de 22; Vector> Geoprocesamiento> La diferencia aparece como mi capa de entrada y la tira WKT como la capa de diferencia; OTF reproject. Hasta ese momento, todo se ve genial. El problema surge después de guardar mi polígono resultante con el mismo CRS personalizado: el polígono guardado es inestable pero el OTF está bien :(
srha

1
gracias por aclarar ... acabo de cargar la capa guardada de mi proyecto (ahora descartado) (guardado usando el cj de proyecto personalizado) y el valor lon_wrap no se muestra en los metadatos de la capa. ese podría ser el problema
Steven Kay

Hmm ¿Sabes cómo arreglar eso? La documentación del proj4 me parece un poco confusa.
Srha
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.