O cálculo da área QGIS difere quando a transformação de CRS on-the-fly está ativada

Quando abro o QGIS, adiciono a camada e calculo as áreas do shapefile por meio da calculadora de campo, recebo uma área diferente do que quando abro o QGIS e marque "Ativar transformação CRS on the fly" e calculo a área. Isso apesar de garantir que o projeto e a camada tenham o mesmo sistema de coordenadas (o mesmo número EPSG). O que estou fazendo de errado?

Eu tenho um shapefile com cálculos de área feitos com ArcGIS (não seja eu, os dados foram entregues a mim e não tenho idéia de qual CRS a área foi calculada com ArcGIS). A camada shapefile CRS é EPSG: 21781 (Suíça). No QGIS, se eu não alterar as configurações do OTF e deixar o CRS do projeto como EPSG: 4326 (WGS84), obtenho o mesmo valor que o valor da área do ArcGIS. No entanto, se eu alterar o OTF antes de adicionar a camada ao EPSG: 21781, recebo valores de área diferentes. Pelo que entendi, isso sugere que a Área ArcGIS foi calculada com o CRS EPSG: 4326.

Primeiro fluxo de trabalho:

abrir QGIS
projeto CRS: EPSG 4326
adicionar camada
o projeto CRS se adapta automaticamente e agora é EPSG 21781
calcular $ área com calculadora de campo

Segundo fluxo de trabalho:

abrir QGIS
projeto CRS: EPSG 4326
Ative o OTF, defina o CRS do projeto como EPSG 21781
adicionar camada
calcular $ área com calculadora de campo

A etapa 5 do primeiro e do segundo fluxo de trabalho NÃO produz a mesma área.

qgis coordinate-system area

— kalakaru
fonte

você pode dar um exemplo do fluxo de trabalho e das ferramentas que você usou; Eu tentei com o recurso on-the-fly ativado e desativado no WGS84 e deu a mesma área. Isso está sendo usado $areana calculadora arquivada. Em suma, on-the-fly afeta como a geometria está sendo exibida sem alterar os dados de fato. Portanto, é mais provável que o erro seja devido ao fluxo de trabalho.

— dof1985

$ area calcula a área com base nas camadas ou no sistema de coordenadas do projeto?

— precisa saber é o seguinte

Eu verifiquei e parece dar a área nas unidades OTF; ainda estou certo de que ele usa a geometria da própria camada

— dof1985

Essa pode ser a raiz do meu problema. Eu tenho um shapefile com cálculos de área feitos com ArcGis (não seja eu, os dados foram entregues a mim e não tenho idéia de qual CRS a área foi calculada com ArcGIS). A camada shapefiley CRS é EPSG: 21781 (Suíça). Se eu não alterar as configurações OTF e deixar o CRS do projeto como EPSG: 4326 (WGS84), obtenho o mesmo valor que o valor da Área ArcGis. No entanto, se eu alterar o OTF antes de adicionar a camada ao EPSG: 21781, recebo valores de área diferentes. Como eu entendo isso sugere que ArcGIS área foi calculada com o CRS EPSG: 4326.

— kalakaru

até onde sei, o Arcgis pode calcular a geometria de várias maneiras. O uso da expressão python da calculadora de campo !shape.area!deve fornecer a área de acordo com a camada crs; calcular a geometria pode funcionar diferente. Portanto, é difícil dizer exatamente o que foi feito em arcgis; no entanto, se você obtiver o mesmo resultado, por exemplo, graus e não metros, significa que o cálculo da área foi realmente baseado no ESPG: 4326.

— dof1985

Respostas:

EDIT - Isenção de responsabilidade: gostaria de encaminhar os leitores para a discussão com ChrisW abaixo. Pode ser que obter uma área baseada em um OTF CRS não seja um bug, afinal; isto é, pelo menos, em arcgis, ele também está sendo usado para permitir o geoprocessamento de duas camadas de diferentes CRS.

Para elaborar sobre a questão acima. Como AndreJ sugeriu e mostrou - este é provavelmente um bug na versão atual do qgis. No entanto, deve-se notar que o problema não é a área errada, mas que a transformação imediata afeta de qualquer maneira os cálculos de área.

O objetivo da transformação / projeção on-the-fly é alinhar dados de diferentes fontes e com diferentes CRS. Isso é principalmente para fins de exibição. O arcmap EG executa automaticamente a projeção on-the-fly em qualquer caso, um CRS de camada não corresponde ao CRS do quadro de dados.

O Arcmap também oferece a possibilidade de editar dados enquanto são projetados on-the-fly, mas também observa que: ( fonte )

No entanto, é importante observar que determinadas operações de edição podem produzir problemas inesperados de alinhamento ou precisão, dependendo dos sistemas de coordenadas que estão sendo usados.

As operações de edição específicas que podem causar problemas incluem alterar as formas dos recursos, ajustar a borda ou o limite dos recursos ou estender e aparar recursos. É mais provável que esses problemas ocorram quando os recursos que você está editando estão próximos à borda ou além da área de uso do sistema de coordenadas

Ou seja: a transformação imediata é menos precisa do que apenas projetar os dados em um CRS diferente (que também apresenta seus próprios problemas).

Dito isto, não é de surpreender que, com base em uma transformação imediata, esteja sendo calculada uma área errada, ainda é surpreendente que o fato de a ativação imediata tenha sido afetada afete de alguma forma o cálculo da geometria, que deve basear-se nos dados. Portanto, não importa se a transformação instantânea se baseia no mesmo ou em um CRS diferente, o cálculo da área deve ser idêntico a cada vez.

Para ser mais prático, se o seu objetivo é calcular a área, não use imediatamente. Se você tiver o CRS errado, projete seus dados.

— dof1985
fonte

Não tenho certeza sobre o QGIS, mas, em contraste com o que você mencionou aqui, o ArcGIS pode realmente calcular sua geometria usando a projeção OTF ou uma projeção completamente diferente dependendo do método (por exemplo, clique com o botão direito do mouse na coluna do atributo e escolha Calcular geometria versus -call / calculadora de campo chamada de shape.area). Às vezes, há opções dadas para usar o CRS de 1) dados / camada, 2) dataframe atual, 3) um CRS especificado não relacionado a 1 ou 2. Normalmente (novamente, ArcGIS), se a escolha não for apresentada, isso será feito em o CRS do dataframe atual, independentemente do que são os dados (daí o OTF).

— Chris W

Também devo mencionar que o OTF não é apenas para fins de exibição - não é necessário reprojetar um conjunto de dados para executar uma ferramenta de geoprocessamento que também usa um conjunto de dados com um CRS diferente; OTF lida com isso. Existem algumas excepções a esta, quando ambos os conjuntos de dados que têm de estar no mesmo CRS.

— Chris W

@ ChrisW, se bem entendi; algumas ferramentas de geoprocessamento aceitam o OTF CRS como era o CRS da camada. Portanto, obter área com base no OTF CRS não é necessariamente um bug. Isso está correto? Em relação à Arcgis, vamos assumir WGS84 como OTF; o que acontece com uma chamada como:!shape.area@meters!

— dof1985

Está correto. Seu quadro de dados e primeira camada podem ser WGS84 e você pode adicionar uma segunda camada que é NAD83. A segunda camada é projetada por OTF, e você pode executar qualquer ferramenta normal como Intersect ou Union e a operação ocorre no WGS84. Obter área definitivamente não é um bug. Eu tenho um cliente que deseja dados no NAD83, mas as informações requerem unidades em acres e eu trabalho em um CRS projetado para inserir informações. Normalmente, apenas altero a projeção do quadro de dados, a área de calcário e depois a troco novamente. Não tenho certeza de como essa chamada seria tratada, pois acho que a conversão de unidades é separada do cálculo.

— 22415 Chris W

Posso confirmar que parece ser um bug.

Crie um arquivo csv com o seguinte conteúdo:

E N
600000 200000
700000 200000
700000 300000
600000 300000

Importe-o como texto delimitado com EPSG: 21781, ative o snap e desenhe um arquivo de forma de polígono nos quatro pontos.

Sem OTF, o resultado $area/1000000.0é de 10000 m² (o que está obviamente correto).

Voltando OTF on , e selecionando o mesmo EPSG: 21781, você começa 9.988,2338 m².

A escolha de um CRS diferente, como o EPSG: 4326, fornece 9990.5339 m², porque o cálculo é feito em um elipsóide diferente (WGS84 em vez de bessel).

Vector --> Geometry Tools --> Export/Add Geometry Columns parece fornecer valores corretos.

O bug já possui alguns tickets: https://issues.qgis.org/issues/10966 e https://issues.qgis.org/issues/12473

— AndreJ
fonte