启用即时CRS转换时，QGIS区域计算有所不同

当我打开QGIS，添加图层并通过字段计算器计算shapefile的面积时，我得到的面积与打开QGIS并选中“启用CRS动态转换”并计算面积的面积不同。尽管要确保项目和图层具有相同的坐标系（相同的EPSG编号），但这仍然可行。我究竟做错了什么？

我有一个shapefile，其中包含使用ArcGIS进行面积计算的信息（不是我自己，数据是交给我的，我不知道使用ArcGIS计算面积的CRS）。形状文件层CRS是EPSG：21781（瑞士）。在QGIS中，如果我不更改OTF设置并将项目CRS保留为EPSG：4326（WGS84），则得到的值与ArcGIS区域值相同。但是，如果在将图层添加到EPSG之前更改了OTF：21781，则会得到不同的面积值。据我了解，这表明ArcGIS Area是使用CRS EPSG：4326计算的。

第一个工作流程：

打开QGIS
项目CRS：EPSG 4326
添加层
项目CRS自动适应，现在为EPSG 21781
使用字段计算器计算$ area

第二个工作流程：

打开QGIS
项目CRS：EPSG 4326
打开OTF，将项目CRS设置为EPSG 21781
添加层
使用字段计算器计算$ area

第一和第二个工作流程的步骤5不要产生相同的区域。

qgis coordinate-system area

— 卡拉卡鲁
source

您能否举例说明您使用的工作流程和工具；我已经在WGS84中启用和禁用了即时启用功能，并给出了相同的区域。那是$area在归档计算器中使用的。简而言之，即时更改会影响几何图形的显示方式，而不会更改实际数据。因此，错误更有可能是由于工作流程引起的。

— dof1985

$ area是否根据图层或项目坐标系计算面积？

— kalakaru 2015年

我检查了一下，似乎该区域以OTF单位显示；但是我非常确定它使用了图层本身的几何形状

— dof1985

那可能是我问题的根源。我有一个用ArcGis进行面积计算的shapefile（不是我，数据是交给我的，我不知道用ArcGIS计算面积的CRS）。形状层CRS为EPSG：21781（瑞士）。如果我不更改OTF设置的并将项目CRS保留为EPSG：4326（WGS84），则得到的值与ArcGis区域值相同。但是，如果在将图层添加到EPSG之前更改了OTF：21781，则会得到不同的面积值。据我所知这表明ArcGIS的面积与CRS EPSG计算：4326

— kalakaru

据我所知，Arcgis可以通过多种方式计算几何。使用字段计算器的python表达式!shape.area!应根据crs层给出面积；比计算几何可能会有所不同。所以这是很难说，究竟什么是ArcGIS中完成的，但如果你得到同样的结果，例如度，而不是米，meens的面积计算是于ESPG确实依据：4326

— dof1985

Answers:

编辑-免责声明：我想请读者参考下面与ChrisW进行的讨论。毕竟，基于OTF CRS来获取区域可能并不是一个错误。也就是说，至少在arcgis中，它还用于允许对来自不同CRS的两层进行地理处理。

详细说明上述问题。正如AndreJ所建议并显示的那样-这可能是qgis当前版本中的错误。但是，应该指出的是，问题不是出在错误的区域上，而是即时转换无论如何都会影响面积计算。

快速转换/投影的目的是使来自不同来源和不同CRS的数据对齐。那主要是出于显示目的。在图层CRS与数据框CRS不匹配的任何情况下，EG arcmap都会自动执行即时投影。

Arcmap还提供了在即时投影时编辑数据的可能性，但还请注意：（source）

但是，必须注意，某些编辑操作可能会产生意外的对齐或精度问题，具体取决于所使用的坐标系。

可能引起问题的特定编辑操作包括更改要素的形状，对齐要素的边缘或边界或扩展和修剪要素。当您正在编辑的要素靠近边缘或超出坐标系的使用范围时，更可能发生这些问题。

就是说：动态转换不仅仅将数据投影到不同的CRS（这也带来了自己的问题）的准确性。

前面已经说过，基于即时转换计算出错误的区域也就不足为奇了，但是令人惊讶的是，启用即时转移的事实以任何方式影响几何的计算，这应该根据数据。因此，即时转换基于相同或不同的CRS无关紧要，每次区域面积计算都应该相同。

更为实际的是，如果您的目的是计算面积，请不要即时使用。如果您的CRS错误，请投影数据。

— dof1985
source

我不确定QGIS，但与您在此处提到的内容形成对比的是，ArcGIS实际上可以使用OTF投影或完全不同的投影来进行其计算几何（具体取决于方法）（即，右键单击属性列，然后选择计算几何与输入-shape / area的代码/字段计算器调用）。有时会给出使用CRS的选择：1）数据/层，2）当前数据帧，3）与1或2不相关的指定CRS。通常（同样，在ArcGIS中）如果不显示该选择，则会在当前数据帧的CRS，无论数据是什么（因此OTF）。

— 克里斯·W

我还要提到OTF不仅用于显示目的-不必重新投影数据集即可运行也使用具有不同CRS的数据集的地理处理工具；OTF可以处理。也有一些例外，当两个数据集都必须在同一个CRS。

— 克里斯·W

@ChrisW，如果我理解正确的话；一些地理处理工具接受OTF CRS，因为它是图层的CRS。因此，基于OTF CRS获取区域不一定是一个错误。那是对的吗？关于Arcgis，让我们假设WGS84为OTF；像这样的电话怎么样：!shape.area@meters!

— dof1985

没错您的数据框和第一层可能是WGS84，您可以添加第二层是NAD83。第二层是OTF投影的，您可以在其上运行任何常规工具，如“相交”或“联合”，并且该操作在WGS84中进行。绝对不占地方。我有一个客户需要NAD83中的数据，但信息需要以英亩为单位，并且我在计划的CRS中工作以输入信息。我通常只是更改数据框投影，计算区域，然后再将其切换回去。由于我认为单位转换与计算是分开的，因此不确定如何处理该调用。

— 克里斯·W

我可以确认这似乎是一个错误。

创建具有以下内容的csv文件：

E N
600000 200000
700000 200000
700000 300000
600000 300000

使用EPSG：21781将其导入为定界文本，启用捕捉并在四个点上绘制多边形shapefile。

如果没有OTF，则结果$area/1000000.0为10000m²（显然是正确的）。

谈到OTF 上，并选择同一EPSG：21781，你会得到9988.2338平方米。

选择不同的CRS，例如EPSG：4326，可提供9990.5339平方米，因为计算是在不同的椭球体上进行的（WGS84代替贝塞尔）。

Vector --> Geometry Tools --> Export/Add Geometry Columns 似乎传递正确的值。

该错误已经有一些故障单：https : //issues.qgis.org/issues/10966和https://issues.qgis.org/issues/12473

— 安德烈·J
source