Die QGIS-Flächenberechnung unterscheidet sich, wenn die CRS-Transformation im laufenden Betrieb aktiviert ist

10

Wenn ich QGIS öffne, die Ebene hinzufüge und die Flächen des Shapefiles über den Feldrechner berechne, erhalte ich eine andere Fläche als beim Öffnen von QGIS und aktiviere "Sofortige CRS-Transformation aktivieren" und berechne die Fläche. Dies gilt trotz der Sicherstellung, dass das Projekt und die Ebene dasselbe Koordinatensystem (dieselbe EPSG-Nummer) haben. Was mache ich falsch?

Ich habe ein Shapefile mit Flächenberechnungen, die mit ArcGIS erstellt wurden (nicht ich, die Daten wurden mir übergeben und ich habe keine Ahnung, für welches CRS die Fläche mit ArcGIS berechnet wurde). Die Shapefile-Schicht CRS ist EPSG: 21781 (Schweiz). Wenn ich in QGIS die OTF-Einstellungen nicht ändere und das Projekt CRS als EPSG: 4326 (WGS84) belasse, erhalte ich denselben Wert wie der ArcGIS-Bereichswert. Wenn ich jedoch den OTF ändere, bevor ich die Ebene zu EPSG: 21781 hinzufüge, erhalte ich unterschiedliche Flächenwerte. Soweit ich weiß, deutet dies darauf hin, dass ArcGIS Area mit dem CRS EPSG: 4326 berechnet wurde.

Erster Workflow:

  1. Öffnen Sie QGIS
  2. Projekt CRS: EPSG 4326
  3. Ebene hinzufügen
  4. Projekt CRS passt sich automatisch an und ist jetzt EPSG 21781
  5. $ Fläche mit Feldrechner berechnen

Zweiter Workflow:

  1. Öffnen Sie QGIS
  2. Projekt CRS: EPSG 4326
  3. Schalten Sie OTF ein und setzen Sie das Projekt CRS auf EPSG 21781
  4. Ebene hinzufügen
  5. $ Fläche mit Feldrechner berechnen

Schritt 5 des ersten und zweiten Workflows erzeugt NICHT den gleichen Bereich.

qgis  coordinate-system  area 
— Kalakaru
quelle
Können Sie ein Beispiel für den von Ihnen verwendeten Workflow und die verwendeten Tools geben? Ich habe es mit aktiviertem und deaktiviertem On-the-Fly im WGS84 versucht und es gab den gleichen Bereich. Das wird $areaim abgelegten Rechner verwendet. Kurz gesagt, On-the-Fly beeinflusst, wie Geometrie angezeigt wird, ohne die Daten de facto zu ändern. Daher ist es wahrscheinlicher, dass der Fehler auf den Workflow zurückzuführen ist.
— dof1985
Berechnet $ area die Fläche basierend auf den Ebenen oder dem Projektkoordinatensystem?
— Kalakaru
Ich habe nachgesehen und es scheint den Bereich in den OTF-Einheiten zu geben; Ich bin mir jedoch ziemlich sicher, dass es die Geometrie der Ebene selbst verwendet
— dof1985
Das könnte die Wurzel meines Problems sein. Ich habe ein Shapefile mit Flächenberechnungen, die mit ArcGis erstellt wurden (nicht ich, die Daten wurden mir übergeben und ich habe keine Ahnung, für welches CRS die Fläche mit ArcGIS berechnet wurde). Die Shapefiley-Schicht CRS ist EPSG: 21781 (Schweiz). Wenn ich die OTF-Einstellungen nicht ändere und das Projekt CRS als EPSG: 4326 (WGS84) belasse, erhalte ich den gleichen Wert wie den ArcGis Area-Wert. Wenn ich jedoch den OTF ändere, bevor ich die Ebene zu EPSG: 21781 hinzufüge, erhalte ich unterschiedliche Flächenwerte. Soweit ich weiß, deutet dies darauf hin, dass ArcGIS Area mit dem CRS EPSG berechnet wurde: 4326.
— Kalakaru
Soweit mir bekannt ist, kann Arcgis die Geometrie auf viele Arten berechnen. Wenn Sie den Python-Ausdruck !shape.area!des Feldrechners verwenden, sollte der Bereich entsprechend der Ebene crs angegeben werden. als Geometrie berechnen könnte anders funktionieren. Es ist also schwer zu sagen, was genau in Arcgis gemacht wurde, aber wenn Sie das gleiche Ergebnis erhalten, z. B. Grad und nicht Meter, bedeutet dies, dass die Flächenberechnung tatsächlich auf dem ESPG basiert: 4326.
— dof1985

Antworten:

6

EDIT - Haftungsausschluss: Ich möchte die Leser auf die Diskussion mit ChrisW unten verweisen. Es kann sein, dass das Abrufen eines Bereichs, der auf einem OTF-CRS basiert, doch kein Fehler ist. Das heißt, zumindest in Arcgis wird es auch verwendet, um die Geoverarbeitung von zwei Schichten aus verschiedenen CRS zu ermöglichen.

Um auf das obige Problem einzugehen. Wie AndreJ vorgeschlagen und gezeigt hat - dies ist wahrscheinlich ein Fehler in der aktuellen Version von qgis. Es sollte jedoch beachtet werden, dass das Problem nicht das falsche Gebiet ist, sondern dass sich die On-the-Fly-Transformation ohnehin auf Gebietsberechnungen auswirkt.

Der Zweck der spontanen Transformation / Projektion besteht darin, Daten aus verschiedenen Quellen und mit verschiedenen CRS auszurichten. Das ist hauptsächlich für Anzeigezwecke. EG arcmap führt automatisch eine On-the-Fly-Projektion durch, in jedem Fall stimmt ein Layer-CRS nicht mit dem Datenrahmen-CRS überein.

Arcmap bietet auch die Möglichkeit, Daten zu bearbeiten, während sie im laufenden Betrieb projiziert werden. Beachten Sie jedoch auch Folgendes: ( Quelle )

Es ist jedoch wichtig zu beachten, dass bestimmte Bearbeitungsvorgänge abhängig von den verwendeten Koordinatensystemen zu unerwarteten Ausrichtungs- oder Genauigkeitsproblemen führen können.

Bestimmte Bearbeitungsvorgänge, die Probleme verursachen können, umfassen das Ändern der Formen von Features, das Einrasten an der Kante oder Grenze von Features oder das Erweitern und Zuschneiden von Features. Diese Probleme treten eher auf, wenn sich die von Ihnen bearbeiteten Features nahe am Rand oder außerhalb des Verwendungsbereichs des Koordinatensystems befinden

Das heißt: Die spontane Transformation ist weniger genau als nur die Projektierung der Daten auf ein anderes CRS (was auch eigene Probleme mit sich bringt).

Es ist jedoch nicht verwunderlich, dass auf der Grundlage einer On-the-Fly-Transformation eine falsche Fläche berechnet wird. Es ist jedoch überraschend, dass die Tatsache, dass On-the-Fly aktiviert wurde, die Berechnung der Geometrie in irgendeiner Weise beeinflusst, die dies sollte auf den Daten basieren. Daher spielt es keine Rolle, ob die On-the-Fly-Transformation auf demselben oder einem anderen CRS basiert. Die Flächenberechnung sollte jedes Mal identisch sein.

Um praktischer zu sein, wenn Sie das Gebiet berechnen möchten, verwenden Sie es nicht im laufenden Betrieb. Wenn Sie das falsche CRS haben, projizieren Sie Ihre Daten.

— dof1985
quelle
Ich bin mir bei QGIS nicht sicher, aber im Gegensatz zu dem, was Sie hier erwähnen, kann ArcGIS die Berechnung der Geometrie mithilfe der OTF-Projektion oder einer völlig anderen Projektion je nach Methode durchführen (dh klicken Sie mit der rechten Maustaste auf die Attributspalte und wählen Sie Geometrie berechnen gegen ein in -code / Feldrechner Aufruf von shape.area). Manchmal werden Auswahlmöglichkeiten für die Verwendung des CRS von 1) Daten / Layer, 2) aktuellem Datenrahmen, 3) einem angegebenen CRS ohne Bezug zu 1 oder 2 angegeben. In der Regel (wieder ArcGIS) wird die Auswahl in ausgeführt, wenn sie nicht angezeigt wird das CRS des aktuellen Datenrahmens, unabhängig davon, um was es sich bei den Daten handelt (daher OTF).
— Chris W
Ich sollte auch erwähnen, dass OTF nicht nur zu Anzeigezwecken dient - man muss kein Dataset neu projizieren, um ein Geoverarbeitungswerkzeug auszuführen, das auch ein Dataset mit einem anderen CRS verwendet. OTF kümmert sich darum. Es gibt einige Ausnahmen, wenn beide Datensätze Sie in dem gleichen CRS sein.
— Chris W
@ChrisW, wenn ich richtig verstehe; Einige Geoverarbeitungswerkzeuge akzeptieren OTF-CRS, da es sich um das CRS der Ebene handelt. Daher ist es nicht unbedingt ein Fehler, einen Bereich basierend auf OTF CRS zu erhalten. Ist das korrekt? In Bezug auf Arcgis nehmen wir WGS84 als OTF an. Was ist mit einem Anruf wie:!shape.area@meters!
— dof1985
Das ist richtig. Ihr Datenrahmen und Ihre erste Schicht könnten WGS84 sein, und Sie könnten eine zweite Schicht hinzufügen, die NAD83 ist. Die zweite Ebene ist OTF-projiziert, und Sie können jedes normale Tool wie Intersect oder Union darauf ausführen, und der Vorgang findet in WGS84 statt. Bereich zu bekommen ist definitiv kein Fehler. Ich habe einen Client, der Daten in NAD83 möchte, aber für die Informationen sind Einheiten in Hektar erforderlich, und ich arbeite in einem projizierten CRS, um Informationen einzugeben. Normalerweise ändere ich einfach die Datenrahmenprojektion, den Berechnungsbereich und schalte sie dann zurück. Ich bin mir nicht sicher, wie dieser Anruf behandelt werden soll, da ich denke, dass die Einheitenumrechnung von der Berechnung getrennt ist.
— Chris W
6

Ich kann bestätigen, dass es ein Fehler zu sein scheint.

Erstellen Sie eine CSV-Datei mit folgendem Inhalt:

E N
600000 200000
700000 200000
700000 300000
600000 300000

Importieren Sie es mit EPSG: 21781 als begrenzten Text, aktivieren Sie das Einrasten und zeichnen Sie ein Polygon-Shapefile auf die vier Punkte.

Ohne OTF ergibt sich ein Ergebnis von $area/1000000.010000 m² (was offensichtlich richtig ist).

Drehen OTF auf und die gleiche EPSG Auswahl: 21781, erhalten Sie 9988,2338 m².

Die Wahl eines anderen CRS wie EPSG: 4326 liefert 9990,5339 m², da die Berechnung auf einem anderen Ellipsoid (WGS84 anstelle von Bessel) erfolgt.

Vector --> Geometry Tools --> Export/Add Geometry Columns scheint korrekte Werte zu liefern.

Der Fehler hat bereits einige Tickets: https://issues.qgis.org/issues/10966 und https://issues.qgis.org/issues/12473

— AndreJ
quelle
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.