オンザフライでCRS変換を有効にすると、QGIS面積の計算が異なります

QGISを開いてレイヤーを追加し、フィールド計算機を介してシェープファイルの面積を計算すると、QGISを開いて「オンザフライCRS変換」をオンにして面積を計算するときとは異なる面積が得られます。これは、プロジェクトとレイヤーが同じ座標系（同じEPSG番号）であることを確認しているにもかかわらずです。何が悪いのですか？

私は、ArcGISで作成された面積計算を含むシェープファイルを持っています（私ではなく、データが私に渡され、ArcGISで面積が計算されたCRSの手掛かりがありません）。シェープファイルレイヤーCRSはEPSG：21781（スイス）です。QGISで、OTF設定を変更せずにプロジェクトCRSをEPSG：4326（WGS84）のままにすると、ArcGISエリア値と同じ値が得られます。ただし、レイヤーをEPSGに追加する前にOTFを変更すると、21781で異なるエリア値が得られます。私が理解しているように、これは、ArcGISエリアがCRS EPSG：4326で計算されたことを示唆しています。

最初のワークフロー：

QGISを開く
プロジェクトCRS：EPSG 4326
レイヤーを追加
プロジェクトCRSは自動的に適応し、現在EPSG 21781です。
フィールド計算機で$ areaを計算する

2番目のワークフロー：

QGISを開く
プロジェクトCRS：EPSG 4326
OTFをオンにし、プロジェクトCRSをEPSG 21781に設定します
レイヤーを追加
フィールド計算機で$ areaを計算する

1番目と2番目のワークフローのステップ5では、同じ領域を作成しないでください。

qgis coordinate-system area

— カラカル
ソース

使用したワークフローとツールの例を教えてください。WGS84でオンザフライを有効または無効にして試してみましたが、同じ領域が得られました。それは$area提出された計算機で使用しています。つまり、オンザフライは、デファクトデータを変更せずに、ジオメトリの表示方法に影響を与えます。したがって、エラーはワークフローが原因である可能性が高くなります。

— dof1985、2015

$ areaはレイヤーまたはプロジェクト座標系に基づいて面積を計算しますか？

— カラカル

私がチェックしたところ、OTFユニットの面積が表示されているようです。それでも、レイヤー自体のジオメトリを使用していると確信しています

— dof1985

それが私の問題の原因かもしれません。ArcGisで作成された面積計算を含むシェープファイルがあります（私ではなく、データが私に渡され、ArcGISで面積が計算されたCRSの手がかりがありません）。ShapefileyレイヤーのCRSはEPSG：21781（スイス）です。OTFの設定を変更せず、プロジェクトのCRSをEPSG：4326（WGS84）のままにすると、ArcGis Areaの値と同じ値が得られます。ただし、EPSGにレイヤーを追加する前にOTFを変更すると、21781で異なるエリア値が得られます。4326：私は、これはArcGISのエリアはCRS EPSGで計算したことを示唆して理解したよう

— kalakaru

私が知る限り、Arcgisはさまざまな方法でジオメトリを計算できます。フィールド計算機のpython式を使用!shape.area!すると、レイヤーcrsに応じた面積が得られます。ジオメトリの計算とは異なる場合があります。それは言うのは難しいですので、正確に何があなたが同じ結果を得るまだ場合、ArcGISで行われた、例えば度とないメーターは、それは面積計算が実際にESPGに基づいていたことをmeens：4326

— dof1985

回答:

編集-免責事項：以下のChrisWとの議論を読者に紹介したいと思います。結局、OTF CRSに基づいてエリアを取得することはバグではないかもしれません。つまり、少なくともarcgisでは、異なるCRSの2つのレイヤーをジオプロセシングできるようにするためにも使用されます。

上記の問題について詳しく説明します。AndreJが示唆して示したように-これはおそらくqgisの現在のバージョンのバグです。ただし、問題は間違った領域ではなく、その場での変換がとにかく面積計算に影響を与えることに注意する必要があります。

オンザフライの変換/投影の目的は、さまざまなソースからのデータをさまざまなCRSに合わせることです。これは主に表示目的です。EGアークマップは、レイヤーCRSがデータフレームCRSと一致しない場合でも、オンザフライ投影を自動的に実行します。

Arcmapは、オンザフライで投影されている間にデータを編集する可能性も提供しますが、次の点にも注意してください。（ソース）

ただし、使用する座標系によっては、特定の編集操作で予期しない位置合わせや精度の問題が発生する可能性があることに注意してください。

問題を引き起こす可能性のある特定の編集操作には、フィーチャの形状の変更、フィーチャのエッジまたは境界へのスナップ、またはフィーチャの延長とトリミングが含まれます。これらの問題は、編集しているフィーチャがエッジに近いか、座標系の使用領域を超えている場合に発生する可能性が高くなります

つまり、その場での変換は、データを別のCRSに投影するよりも正確ではありません（独自の問題も発生します）。

オンザフライ変換に基づいて間違った領域が計算されていることは驚くべきことではないと述べましたが、オンザフライが有効にされたという事実が何らかの形でジオメトリの計算に影響を与えることは驚くべきことです。データに基づいている。したがって、オンザフライ変換が同じまたは異なるCRSに基づいているかどうかは関係ありません。面積計算は毎回同じでなければなりません。

より実用的には、エリアを計算することが目的である場合は、オンザフライを使用しないでください。間違ったCRSがある場合は、データを投影します。

— dof1985
ソース

QGISについてはわかりませんが、ArcGISは実際にOTFプロジェクションを使用してジオメトリを計算することができますが、方法に応じて完全に異なるプロジェクションを実行できます（つまり、属性列を右クリックして[ジオメトリを計算]を選択します。 -shape / areaのコード/フィールド計算機呼び出し）。1）データ/レイヤー、2）現在のデータフレーム、3）1または2に関係のない指定されたCRSのCRSを使用するための選択肢がときどきあります。一般に（ここでも、ArcGIS）選択肢が提示されない場合は、データが何であるかに関係なく（したがってOTF）、現在のデータフレームのCRS

— クリスW

また、OTFは単なる表示目的ではないことも言及しておきます。異なるCRSのデータセットも使用するジオプロセシングツールを実行するために、データセットを再投影する必要はありません。OTFはそれを処理します。これにはいくつかの例外があり、両方のデータセットが同じCRSにある必要があります。

— クリスW

@ChrisW、私が正しく理解した場合。一部のジオプロセシングツールは、レイヤーのCRSであるため、OTF CRSを受け入れます。したがって、OTF CRSに基づいて領域を取得することは、必ずしもバグではありません。あれは正しいですか？Arcgisについて、WGS84をOTFと仮定します。どのような呼び出しについて：!shape.area@meters!

— dof1985

そのとおりです。データフレームと最初のレイヤーはWGS84で、2番目のレイヤーであるNAD83を追加できます。2番目のレイヤーはOTF投影であり、交差やユニオンなどの通常のツールを実行でき、操作はWGS84で行われます。エリアを取得することは間違いなくバグではありません。NAD83でデータを必要とするクライアントがありますが、情報にはエーカー単位の単位が必要であり、投影されたCRSで情報を入力するように作業しています。私は通常、データフレームの投影、計算領域を変更してから、元に戻します。単位変換は計算とは別なので、その呼び出しがどのように処理されるかはわかりません。

— クリスW

バグと思われます。

次の内容のcsvファイルを作成します。

E N
600000 200000
700000 200000
700000 300000
600000 300000

EPSG：21781で区切られたテキストとしてインポートし、スナップを有効にして、4点にポリゴンシェープファイルを描画します。

OTFがない場合、の結果は10000m²になり$area/1000000.0ます（これは明らかに正しいです）。

OTFをオンにして同じEPSG：21781を選択すると、9988.2338m²になります。

EPSG：4326などの別のCRSを選択すると、計算が別の楕円体（ベッセルの代わりにWGS84）で行われるため、9990.5339m²になります。

Vector --> Geometry Tools --> Export/Add Geometry Columns 正しい値を提供するようです。

バグにはすでにいくつかのチケットがあります：https : //issues.qgis.org/issues/10966およびhttps://issues.qgis.org/issues/12473

— AndreJ
ソース