El cálculo del área QGIS difiere cuando se activa la transformación CRS sobre la marcha

Cuando abro QGIS, agrego la capa y calculo las áreas del archivo de forma a través de la calculadora de campo, obtengo un área diferente que cuando abro QGIS y marco "Activar la transformación CRS sobre la marcha" y calculo el área. Esto es a pesar de asegurarse de que el proyecto y la capa tengan el mismo sistema de coordenadas (mismo número EPSG). ¿Qué estoy haciendo mal?

Tengo un archivo de forma con cálculos de área realizados con ArcGIS (no soy yo, me entregaron los datos y no tengo idea de qué CRS se calculó el área con ArcGIS). La capa de archivo de forma CRS es EPSG: 21781 (Suiza). En QGIS, si no cambio la configuración de OTF y dejo el proyecto CRS como EPSG: 4326 (WGS84) obtengo el mismo valor que el valor del área ArcGIS. Sin embargo, si cambio el OTF antes de agregar la capa a EPSG: 21781 obtengo valores de área diferentes. Según tengo entendido, esto sugiere que ArcGIS Area se calculó con el CRS EPSG: 4326.

Primer flujo de trabajo:

abrir QGIS
proyecto CRS: EPSG 4326
agregar capa
proyecto CRS se adapta automáticamente y ahora es EPSG 21781
calcular $ area con calculadora de campo

Segundo flujo de trabajo:

abrir QGIS
proyecto CRS: EPSG 4326
Active OTF, configure el proyecto CRS en EPSG 21781
agregar capa
calcular $ area con calculadora de campo

El paso 5 del primer y segundo flujo de trabajo NO produce la misma área.

qgis coordinate-system area

— kalakaru
fuente

¿Puede dar un ejemplo del flujo de trabajo y las herramientas que utilizó? Lo probé con el WGS84 activado y desactivado sobre la marcha y me dio la misma área. Eso está usando $areaen la calculadora archivada. En resumen, sobre la marcha afecta cómo se muestra la geometría sin alterar los datos de facto. Por lo tanto, es más probable que el error se deba al flujo de trabajo.

— dof1985

¿$ area calcula el área en función de las capas o del sistema de coordenadas del proyecto?

— kalakaru

Lo he comprobado y parece dar el área en las unidades OTF; Sin embargo, estoy bastante seguro de que utiliza la geometría de la capa en sí misma

— dof1985

Esa podría ser la raíz de mi problema. Tengo un shapefile con cálculos de área realizados con ArcGis (no soy yo, los datos me fueron entregados y no tengo idea de qué CRS se calculó el área con ArcGIS). La capa de shapefiley CRS es EPSG: 21781 (Suiza). Si no cambio la configuración de OTF y dejo el proyecto CRS como EPSG: 4326 (WGS84) obtengo el mismo valor que el valor del Área ArcGis. Sin embargo, si cambio el OTF antes de agregar la capa a EPSG: 21781 obtengo valores de área diferentes. Según tengo entendido, esto sugiere que el área ArcGIS se calculó con el CRS EPSG: 4326.

— kalakaru

Que yo sepa, Arcgis puede calcular la geometría de muchas maneras. El uso de la expresión python de la calculadora de campo !shape.area!debería dar el área de acuerdo con la capa crs; que calcular la geometría podría funcionar de manera diferente. Por lo tanto, es difícil saber exactamente qué se hizo en arcgis, pero si obtiene el mismo resultado, por ejemplo, grados y no metros, significa que el cálculo del área se basó en el ESPG: 4326.

— dof1985

Respuestas:

EDITAR - Descargo de responsabilidad: me gustaría referir a los lectores a la discusión con ChrisW a continuación. Puede ser que obtener un área basada en un OTF CRS no sea un error después de todo; es decir, al menos, en arcgis también se usa para permitir el geoprocesamiento de dos capas de diferentes CRS.

Para elaborar sobre el tema anterior. Como AndreJ lo sugirió y lo demostró, este es probablemente un error en la versión actual de qgis. Sin embargo, debe tenerse en cuenta que el problema no es el área incorrecta, sino que la transformación sobre la marcha afecta de todos modos los cálculos del área.

El propósito de la transformación / proyección sobre la marcha es alinear datos de diferentes fuentes y con diferentes CRS. Eso es principalmente para fines de visualización. Por ejemplo, arcmap realiza automáticamente la proyección sobre la marcha en cualquier caso, un CRS de capa no coincide con el marco de datos CRS.

Arcmap también ofrece la posibilidad de editar datos mientras se proyecta sobre la marcha, pero también señala que: ( fuente )

Sin embargo, es importante tener en cuenta que ciertas operaciones de edición pueden producir problemas inesperados de alineación o precisión, dependiendo de los sistemas de coordenadas que se utilicen.

Las operaciones de edición específicas que pueden causar problemas incluyen cambiar las formas de las características, ajustar el borde o el límite de las características o ampliar y recortar las características. Es más probable que estos problemas ocurran cuando las características que está editando están cerca del borde o más allá del área de uso del sistema de coordenadas

Es decir: la transformación sobre la marcha es menos precisa que proyectar los datos en un CRS diferente (que también presenta sus propios problemas).

Habiendo dicho eso, no es sorprendente que, basándose en una transformación sobre la marcha, se esté calculando un área incorrecta, sin embargo, es sorprendente que el hecho de que se haya habilitado sobre la marcha afecta de alguna manera el cálculo de la geometría, lo que debería basarse en los datos. Por lo tanto, no importa si la transformación sobre la marcha se basa en el mismo o diferente CRS, el cálculo del área debe ser idéntico cada vez.

Para ser más práctico, si su objetivo es calcular el área, no utilice sobre la marcha. Si tiene el CRS incorrecto, proyecte sus datos.

— dof1985
fuente

No estoy seguro acerca de QGIS, pero en contraste con lo que menciona aquí, ArcGIS puede hacer su Calcular Geometría usando proyección OTF o una proyección completamente diferente dependiendo del método (es decir, hacer clic con el botón derecho en la columna de atributos y elegir Calcular Geometría vs un -código / llamada de calculadora de campo de shape.area). A veces se ofrecen opciones para usar el CRS de 1) datos / capa, 2) marco de datos actual, 3) un CRS especificado no relacionado con 1 o 2. Por lo general (nuevamente, ArcGIS) si la opción no se presenta, se realizará en el CRS del marco de datos actual, independientemente de cuáles sean los datos (de ahí OTF).

— Chris W

También debo mencionar que OTF no es solo para fines de visualización: no es necesario volver a proyectar un conjunto de datos para ejecutar una herramienta de geoprocesamiento que también utiliza un conjunto de datos con un CRS diferente; OTF se encarga de eso. Hay algunas excepciones a esto, cuando ambos conjuntos de datos no tienen que estar en el mismo SIR.

— Chris W

@ChrisW, si entiendo correctamente; Algunas herramientas de geoprocesamiento aceptan OTF CRS, ya que era el CRS de la capa. Por lo tanto, obtener un área basada en OTF CRS no es necesariamente un error. ¿Es eso correcto? Con respecto a Arcgis, supongamos WGS84 como OTF; ¿qué tal una llamada como:!shape.area@meters!

— dof1985

Eso es correcto. Su marco de datos y su primera capa podrían ser WGS84, y podría agregar una segunda capa que sea NAD83. La segunda capa está proyectada por OTF, y puede ejecutar cualquier herramienta normal como Intersect o Union en ella y la operación se lleva a cabo en WGS84. Obtener área definitivamente no es un error. Tengo un cliente que quiere datos en NAD83, pero la información requiere unidades en acres y que trabajo en un CRS proyectado para ingresar información. Por lo general, solo cambio la proyección del marco de datos, el área de cálculo y luego lo vuelvo a cambiar. No estoy seguro de cómo se manejaría esa llamada, ya que creo que la conversión de unidades está separada del cálculo.

— Chris W

Puedo confirmar que parece ser un error.

Cree un archivo csv con el siguiente contenido:

E N
600000 200000
700000 200000
700000 300000
600000 300000

Importarlo como texto delimitado con EPSG: 21781, habilitar el ajuste y dibujar un archivo de forma poligonal en los cuatro puntos.

Sin OTF, el resultado $area/1000000.0es de 10000 m² (lo cual es obviamente correcto).

Volviendo OTF en , y la selección de la misma EPSG: 21781, se obtiene 9988,2338 m².

Elegir un CRS diferente, como EPSG: 4326, ofrece 9990.5339 m², porque el cálculo se realiza en un elipsoide diferente (WGS84 en lugar de bessel).

Vector --> Geometry Tools --> Export/Add Geometry Columns Parece entregar valores correctos.

El error ya tiene algunas entradas: https://issues.qgis.org/issues/10966 y https://issues.qgis.org/issues/12473

— AndreJ
fuente