Il calcolo dell'area QGIS differisce quando è abilitata la trasformazione CRS al volo

Quando apro QGIS, aggiungo il livello e calcolo le aree del file di forma tramite il calcolatore di campo ottengo un'area diversa rispetto a quando apro QGIS e controllo "Abilita trasformazione CRS al volo" e calcolo l'area. Ciò nonostante si assicuri che il progetto e il livello abbiano lo stesso sistema di coordinate (stesso numero EPSG). Che cosa sto facendo di sbagliato?

Ho uno shapefile con calcoli di area effettuati con ArcGIS (non essere io, i dati mi sono stati consegnati e non ho idea di quale CRS l'area è stata calcolata con ArcGIS). Lo strato di file di forma CRS è EPSG: 21781 (Svizzera). In QGIS, se non modifico le impostazioni OTF e lascio il progetto CRS come EPSG: 4326 (WGS84) ottengo lo stesso valore del valore dell'area ArcGIS. Tuttavia, se cambio OTF prima di aggiungere il layer a EPSG: 21781 ottengo valori di area diversi. A quanto ho capito, questo suggerisce che ArcGIS Area è stata calcolata con il CRS EPSG: 4326.

Primo flusso di lavoro:

apri QGIS
progetto CRS: EPSG 4326
aggiungi livello
il progetto CRS si adatta automaticamente ed è ora EPSG 21781
calcola $ area con il calcolatore di campo

Secondo flusso di lavoro:

apri QGIS
progetto CRS: EPSG 4326
Attiva OTF, imposta il progetto CRS su EPSG 21781
aggiungi livello
calcola $ area con il calcolatore di campo

Il passaggio 5 del primo e del secondo flusso di lavoro NON produce la stessa area.

qgis coordinate-system area

— kalakaru
fonte

puoi fare un esempio del flusso di lavoro e degli strumenti che hai usato; L'ho provato al volo abilitato e disabilitato nel WGS84 e ha dato la stessa area. Quello sta usando $areanel calcolatore archiviato. In breve, al volo influenza il modo in cui la geometria viene visualizzata senza alterare i dati di fatto. Pertanto è più probabile che l'errore sia dovuto al flusso di lavoro.

— dof1985,

$ area calcola l'area in base agli strati o al sistema di coordinate dei progetti?

— Kalakaru,

Ho controllato e sembra dare l'area nelle unità OTF; tuttavia sono abbastanza sicuro che utilizza la geometria del livello stesso

— dof1985,

Potrebbe essere la radice del mio problema. Ho uno shapefile con Calcoli area fatti con ArcGis (non essere io, i dati mi sono stati consegnati e non ho idea di quale CRS l'area è stata calcolata con ArcGIS). Il layer Shapefiley CRS è EPSG: 21781 (Svizzera). Se non modifico le impostazioni OTF e lascio il progetto CRS come EPSG: 4326 (WGS84) ottengo lo stesso valore del valore Area ArcGis. Tuttavia, se cambio OTF prima di aggiungere il layer a EPSG: 21781 ottengo valori di area diversi. A quanto ho capito, questo suggerisce che l'Area ArcGIS è stata calcolata con l'EPSG CRS: 4326.

— Kalakaru,

per quanto ne so, Arcgis può calcolare la geometria in molti modi. L'uso dell'espressione python della calcolatrice di campo !shape.area!dovrebbe dare l'area in base al livello crs; di calcolare la geometria potrebbe funzionare in modo diverso. Quindi è difficile dire esattamente cosa è stato fatto in Arcgis, ma se si ottiene lo stesso risultato, ad esempio gradi e non metri, si suppone che il calcolo dell'area fosse effettivamente basato sull'ESPG: 4326.

— dof1985,

Risposte:

EDIT - Dichiarazione di non responsabilità: vorrei sottoporre i lettori alla discussione con ChrisW di seguito. Dopotutto potrebbe essere che ottenere un'area basata su un CRS OTF non sia un bug; cioè, almeno, nelle arcgis viene anche usato per consentire il geoprocessing di due strati da diversi CRS.

Per approfondire il problema sopra. Come AndreJ ha suggerito e mostrato - questo è probabilmente un bug nella versione corrente di qgis. Tuttavia, va notato che il problema non è l'area sbagliata, ma che la trasformazione al volo influisce comunque sui calcoli dell'area.

Lo scopo della trasformazione / proiezione al volo è di allineare i dati da fonti diverse e con CRS diversi. Questo è principalmente a scopo di visualizzazione. EG arcmap esegue automaticamente la proiezione al volo in ogni caso un CRS di livello non corrisponde al CRS del frame di dati.

Arcmap offre anche la possibilità di modificare i dati durante la proiezione al volo, ma nota anche che: ( fonte )

Tuttavia, è importante notare che alcune operazioni di modifica possono produrre inaspettati problemi di allineamento o precisione, a seconda dei sistemi di coordinate utilizzati.

Operazioni di modifica specifiche che possono causare problemi includono la modifica delle forme delle funzioni, l'aggancio al limite o il limite delle funzioni o l'estensione e il taglio delle funzioni. È più probabile che questi problemi si verifichino quando le funzioni che si stanno modificando sono vicine al bordo o oltre l'area di utilizzo del sistema di coordinate

Vale a dire: la trasformazione al volo è meno accurata della semplice proiezione dei dati su un CRS diverso (che introduce anche i propri problemi).

Detto questo, non sorprende che sulla base di una trasformazione al volo venga calcolata un'area errata, tuttavia è sorprendente che il fatto che la funzione al volo sia stata abilitata influisca in qualche modo sul calcolo della geometria, che dovrebbe basarsi sui dati. Pertanto, non importa se la trasformazione al volo si basa sullo stesso o su un CRS diverso, il calcolo dell'area deve essere identico ogni volta.

Per essere più pratici, se il tuo obiettivo è calcolare l'area non usare al volo. Se hai il CRS sbagliato, proiettare i tuoi dati.

— dof1985
fonte

Non sono sicuro di QGIS, ma in contrasto con quanto menzionato qui ArcGIS può effettivamente fare la sua Calculate Geometry usando la proiezione OTF o una proiezione completamente diversa a seconda del metodo (es. Fare clic con il tasto destro sulla colonna degli attributi e scegliere Calculate Geometry vs an in in -code / field call call of shape.area). A volte sono disponibili opzioni per utilizzare il CRS di 1) dati / layer, 2) frame di dati corrente, 3) un CRS specificato non correlato a 1 o 2. In genere (di nuovo, ArcGIS) se la scelta non viene presentata, verrà eseguita in il CRS del dataframe corrente, indipendentemente da quali siano i dati (quindi OTF).

— Chris W,

Dovrei anche menzionare OTF non solo per scopi di visualizzazione: non è necessario riproiettare un set di dati per eseguire uno strumento di geoprocessing che utilizza anche un set di dati con un CRS diverso; OTF lo gestisce. Ci sono alcune eccezioni a questo, quando entrambi i set di dati non devono essere nelle stesse CRS.

— Chris W,

@ChrisW, se ho capito bene; alcuni strumenti di geoprocessing accettano CRS OTF poiché era il CRS del livello. Quindi ottenere un'area basata su OTF CRS non è necessariamente un bug. È corretto? Per quanto riguarda Arcgis, supponiamo che WGS84 sia OTF; che dire di una chiamata come:!shape.area@meters!

— dof1985,

È corretto. Il tuo frame di dati e il primo layer potrebbero essere WGS84 e potresti aggiungere un secondo layer NAD83. Il secondo livello è proiettato OTF e su di esso è possibile eseguire qualsiasi strumento normale come Intersect o Union e l'operazione si svolge in WGS84. Ottenere l'area sicuramente non è un bug. Ho un client che desidera dati in NAD83, ma le informazioni richiedono unità in acri e che lavoro in un CRS proiettato per inserire le informazioni. Di solito cambio semplicemente la proiezione del frame di dati, l'area di calcolo e poi lo cambio. Non sono sicuro di come verrà gestita quella chiamata poiché penso che la conversione di unità sia separata dal calcolo.

— Chris W,

Posso confermare che sembra essere un bug.

Creare un file CSV con il seguente contenuto:

E N
600000 200000
700000 200000
700000 300000
600000 300000

Importalo come testo delimitato con EPSG: 21781, abilita lo snap e disegna un file di forma poligonale sui quattro punti.

Senza OTF, il risultato $area/1000000.0è di 10000 m² (che è ovviamente corretto).

Girando OTF su , e selezionando la stessa EPSG: 21781, si ottiene 9988,2338 m².

La scelta di un CRS diverso, come EPSG: 4326, eroga 9990,5339 m², poiché il calcolo viene eseguito su un diverso ellissoide (WGS84 anziché Bessel).

Vector --> Geometry Tools --> Export/Add Geometry Columns sembra fornire valori corretti.

Il bug ha già alcuni ticket: https://issues.qgis.org/issues/10966 e https://issues.qgis.org/issues/12473

— ANDREJ
fonte