Obliczanie obszaru QGIS różni się, gdy włączona jest transformacja CRS w locie

Kiedy otwieram QGIS, dodaj warstwę i obliczam obszary pliku kształtu za pomocą kalkulatora pola, otrzymuję inny obszar niż po otwarciu QGIS i zaznaczam „Włącz transformację CRS w locie” i obliczam obszar. Dzieje się tak pomimo upewnienia się, że projekt i warstwa mają ten sam układ współrzędnych (ten sam numer EPSG). Co ja robię źle?

Mam plik kształtu z obliczeniami powierzchni wykonanymi za pomocą ArcGIS (nie bądź mną, dane zostały mi przekazane i nie mam pojęcia, dla którego CRS obszar został obliczony za pomocą ArcGIS). Warstwa kształtu pliku CRS to EPSG: 21781 (Szwajcaria). W QGIS, jeśli nie zmienię ustawień OTF i pozostawię projekt CRS jako EPSG: 4326 (WGS84), otrzymam taką samą wartość jak wartość obszaru ArcGIS. Jeśli jednak zmienię OTF przed dodaniem warstwy do EPSG: 21781, otrzymam różne wartości powierzchni. Jak rozumiem, sugeruje to, że obszar ArcGIS został obliczony za pomocą CRS EPSG: 4326.

Pierwszy przepływ pracy:

otwórz QGIS
projekt CRS: EPSG 4326
dodaj warstwę
projekt CRS dostosowuje się automatycznie i jest teraz EPSG 21781
obliczyć $ area za pomocą kalkulatora pola

Drugi przepływ pracy:

otwórz QGIS
projekt CRS: EPSG 4326
Włącz OTF, ustaw projekt CRS na EPSG 21781
dodaj warstwę
obliczyć $ area za pomocą kalkulatora pola

Krok 5 pierwszego i drugiego przepływu pracy NIE produkuj tego samego obszaru.

qgis coordinate-system area

— kalakaru
źródło

czy możesz podać przykład przepływu pracy i użytych narzędzi; Próbowałem z włączoną i wyłączoną w locie w WGS84 i dało to ten sam obszar. To jest używane $areaw złożonym kalkulatorze. Krótko mówiąc, „w locie” wpływa na sposób wyświetlania geometrii bez faktycznej zmiany danych. Dlatego bardziej prawdopodobne jest, że błąd wynika z przepływu pracy.

— dof1985

Czy $ area oblicza powierzchnię na podstawie warstw lub układu współrzędnych projektu?

— kalakaru 18.04.15

Sprawdziłem i wydaje się, że podaje obszar w jednostkach OTF; jednak jestem pewien, że wykorzystuje geometrię samej warstwy

— dof1985

To może być źródłem mojego problemu. Mam plik kształtu z obliczeniami obszaru wykonanymi za pomocą ArcGis (nie bądź mną, dane zostały mi przekazane i nie mam pojęcia, dla którego CRS obszar został obliczony za pomocą ArcGIS). Shapefiley layer CRS to EPSG: 21781 (Szwajcaria). Jeśli nie zmienię ustawień OTF i pozostawię CRS projektu jako EPSG: 4326 (WGS84), otrzymam taką samą wartość jak wartość ArcGis Area. Jeśli jednak zmienię OTF przed dodaniem warstwy do EPSG: 21781, otrzymam różne wartości powierzchni. Jak rozumiem, sugeruje to, że Obszar ArcGIS został obliczony za pomocą CRS EPSG: 4326.

— kalakaru

o ile mi wiadomo Arcgis może obliczyć geometrię na wiele sposobów. Użycie wyrażenia python kalkulatora pola !shape.area!powinno dać obszar zgodnie z warstwą crs; niż obliczyć, geometria może działać inaczej. Więc trudno powiedzieć, co dokładnie zostało zrobione w ArcGIS, ale jeśli uzyska ten sam wynik, np stopni, a nie metry, to meens że obliczenie obszar rzeczywiście opiera się na ESPG: 4326.

— dof1985

Odpowiedzi:

EDYCJA - Zastrzeżenie: Chciałbym skierować czytelników do dyskusji z ChrisW poniżej. Może się zdarzyć, że uzyskanie obszaru w oparciu o CRS OTF nie jest wcale błędem; to znaczy przynajmniej w arkgis, jest również wykorzystywany do geoprzetwarzania dwóch warstw z różnych CRS.

Aby rozwinąć powyższy problem. Jak sugeruje AndreJ i pokaż - jest to prawdopodobnie błąd w obecnej wersji qgis. Należy jednak zauważyć, że problemem nie jest niewłaściwy obszar, ale transformacja w czasie rzeczywistym wpływa na obliczenia powierzchni.

Celem transformacji / projekcji w locie jest wyrównanie danych z różnych źródeł i różnych CRS. Jest to głównie do celów wyświetlania. EG arcmap automatycznie wykonuje rzutowanie w locie w każdym przypadku, gdy CRS warstwy nie pasuje do CRS ramki danych.

Arcmap zapewnia również możliwość edycji danych podczas wyświetlania w locie, ale zauważa również, że: ( źródło )

Należy jednak pamiętać, że niektóre operacje edycji mogą powodować nieoczekiwane problemy z wyrównaniem lub dokładnością, w zależności od używanych układów współrzędnych.

Konkretne operacje edycji, które mogą powodować problemy, obejmują zmianę kształtów operacji, przyciąganie do krawędzi lub granicy operacji lub rozszerzanie i przycinanie operacji. Problemy te częściej występują, gdy edytowane elementy znajdują się blisko krawędzi lub poza obszarem zastosowania układu współrzędnych

Innymi słowy: transformacja w locie jest mniej dokładna niż tylko rzutowanie danych do innego CRS (co również wprowadza własne problemy).

Powiedziawszy, że nie jest zaskakujące, że na podstawie transformacji w locie obliczany jest niewłaściwy obszar, ale zaskakujące jest to, że fakt włączenia w locie wpływa w jakikolwiek sposób na obliczenia geometrii, które powinny być oparte na danych. Dlatego nie ma znaczenia, czy transformacja w locie jest oparta na tym samym lub innym CRS, obliczanie powierzchni powinno być za każdym razem identyczne.

Aby być bardziej praktycznym, jeśli Twoim celem jest obliczenie obszaru, nie używaj go w locie. Jeśli masz zły CRS, wyświetl swoje dane.

— dof1985
źródło

Nie jestem pewien co do QGIS, ale w przeciwieństwie do tego, o czym tu wspominasz, ArcGIS może faktycznie wykonać obliczenia geometrii za pomocą projekcji OTF lub zupełnie innej projekcji w zależności od metody (tj. Kliknij kolumnę atrybutu prawym przyciskiem myszy i wybierz opcję Oblicz geometrię vs -kod / kalkulator polowy wywołanie kształtu. obszar). Czasami są dostępne opcje użycia CRS dla 1) danych / warstwy, 2) bieżącej ramki danych, 3) określonego CRS niezwiązanego z 1 lub 2. Zazwyczaj (ponownie, ArcGIS), jeśli nie zostanie przedstawiony, zostanie to zrobione w CRS bieżącej ramki danych, niezależnie od tego, co to są dane (stąd OTF).

— Chris W

Powinienem również wspomnieć, że OTF nie służy wyłącznie do wyświetlania - nie trzeba ponownie rzutować zestawu danych, aby uruchomić narzędzie geoprzetwarzania, które również używa zestawu danych z innym CRS; OTF sobie z tym radzi. Istnieją pewne wyjątki od tej, gdy oba zbiory danych nie muszą być w tym samym KSR.

— Chris W

@ChrisW, jeśli dobrze rozumiem; niektóre narzędzia geoprzetwarzania akceptują OTF CRS, ponieważ był to CRS warstwy. Zatem uzyskanie obszaru opartego na OTF CRS niekoniecznie jest błędem. Czy to jest poprawne? Jeśli chodzi o Arcgis, załóżmy, że WGS84 jest OTF; co z rozmową, taką jak:!shape.area@meters!

— dof1985

To jest poprawne. Ramką danych i pierwszą warstwą może być WGS84, a możesz dodać drugą warstwę, którą jest NAD83. Druga warstwa jest projektowana przez OTF i można na niej uruchomić dowolne normalne narzędzie, takie jak Intersect lub Union, a operacja odbywa się w WGS84. Uzyskanie obszaru zdecydowanie nie jest błędem. Mam klienta, który chce danych w NAD83, ale informacje wymagają jednostek w akrach i że pracuję w projektowanym CRS, aby wprowadzić informacje. Zwykle po prostu zmieniam projekcję ramki danych, obliczam obszar, a następnie przełączam go z powrotem. Nie jestem pewien, jak to połączenie zostanie obsłużone, ponieważ myślę, że konwersja jednostek jest oddzielna od obliczeń.

— Chris W

Mogę potwierdzić, że wydaje się, że to błąd.

Utwórz plik csv o następującej treści:

E N
600000 200000
700000 200000
700000 300000
600000 300000

Zaimportuj go jako tekst rozdzielany za pomocą EPSG: 21781, włącz przyciąganie i narysuj plik kształtu wielokąta na czterech punktach.

Bez OTF wynik $area/1000000.0to 10000 m² (co oczywiście jest poprawne).

Przechodząc OTF na i wybierając tę samą EPSG: 21781, masz 9988.2338 m².

Wybór innego CRS, takiego jak EPSG: 4326, zapewnia 9990,5339 m², ponieważ obliczenia są wykonywane na innej elipsoidzie (WGS84 zamiast bessel).

Vector --> Geometry Tools --> Export/Add Geometry Columns wydaje się dostarczać prawidłowe wartości.

Błąd ma już kilka zgłoszeń: https://issues.qgis.org/issues/10966 i https://issues.qgis.org/issues/12473

— AndreJ
źródło