Tính toán diện tích của QGIS khác nhau khi bật chuyển đổi CRS

Khi tôi mở QGIS, thêm lớp và tính toán các khu vực của shapefile thông qua máy tính trường, tôi nhận được một khu vực khác so với khi tôi mở QGIS và kiểm tra "Bật khi chuyển đổi CRS bay" và tính diện tích. Điều này mặc dù đảm bảo rằng dự án và lớp có cùng hệ thống Tọa độ (cùng số EPSG). Tôi đang làm gì sai?

Tôi có một shapefile với các tính toán diện tích được thực hiện với ArcGIS (không phải là tôi, dữ liệu được trao cho tôi và tôi không biết CRS khu vực nào được tính toán với ArcGIS). Lớp CRS của shapefile là EPSG: 21781 (Thụy Sĩ). Trong QGIS, nếu tôi không thay đổi cài đặt OTF và để CRS dự án là EPSG: 4326 (WGS84), tôi sẽ nhận được cùng giá trị với giá trị khu vực ArcGIS. Tuy nhiên, nếu tôi thay đổi OTF trước khi thêm lớp vào EPSG: 21781, tôi nhận được các giá trị khu vực khác nhau. Theo tôi hiểu điều này cho thấy ArcGIS Area đã được tính toán với CRS EPSG: 4326.

Quy trình làm việc đầu tiên:

mở QGIS
CRS dự án: EPSG 4326
thêm lớp
CRS dự án tự động điều chỉnh và bây giờ là EPSG 21781
tính toán diện tích $ với máy tính trường

Quy trình làm việc thứ hai:

mở QGIS
CRS dự án: EPSG 4326
Bật OTF, đặt CRS dự án thành EPSG 21781
thêm lớp
tính toán diện tích $ với máy tính trường

Bước 5 của quy trình làm việc thứ nhất và thứ hai KHÔNG tạo ra cùng một khu vực.

qgis coordinate-system area

— kalakaru
nguồn

bạn có thể đưa ra một ví dụ về quy trình làm việc và các công cụ bạn đã sử dụng; Tôi đã thử nó với tính năng kích hoạt và vô hiệu hóa trong WGS84 và nó cho cùng một khu vực. Đó là sử dụng $areatrong máy tính nộp. Nói tóm lại, trên đường bay ảnh hưởng đến cách hiển thị hình học mà không làm thay đổi dữ liệu thực tế. Do đó, nhiều khả năng là do lỗi công việc.

— dof1985

$ area tính diện tích dựa trên các lớp hoặc hệ tọa độ dự án?

— kalakaru

Tôi đã kiểm tra và dường như cung cấp cho khu vực trong các đơn vị OTF; nhưng tôi khá chắc chắn rằng nó sử dụng hình học của chính lớp đó

— dof1985

Đó có thể là gốc rễ của vấn đề của tôi. Tôi có một shapefile với Tính toán diện tích được thực hiện với ArcGis (không phải là tôi, dữ liệu được trao cho tôi và tôi không biết CRS khu vực nào được tính toán với ArcGIS). Lớp CRS của shapefiley là EPSG: 21781 (Thụy Sĩ). Nếu tôi không thay đổi cài đặt OTF và để CRS dự án là EPSG: 4326 (WGS84), tôi sẽ nhận được cùng giá trị với giá trị ArcGis Area. Tuy nhiên, nếu tôi thay đổi OTF trước khi thêm lớp vào EPSG: 21781, tôi nhận được các giá trị khu vực khác nhau. Theo tôi hiểu điều này cho thấy rằng ArcGIS Area đã được tính toán với CRS EPSG: 4326.

— kalakaru

theo như tôi biết Arcgis có thể tính toán hình học theo nhiều cách. Sử dụng biểu thức python của máy tính trường !shape.area!sẽ cung cấp cho khu vực theo lớp crs; hơn tính toán hình học có thể làm việc khác nhau. Vì vậy, thật khó để nói, chính xác những gì đã được thực hiện trong arcgis, tuy nhiên nếu bạn nhận được kết quả tương tự, ví dụ độ và không mét, thì điều đó cho thấy việc tính toán diện tích thực sự dựa trên ESPG: 4326.

— dof1985

Câu trả lời:

EDIT - Tuyên bố miễn trừ trách nhiệm: Tôi muốn giới thiệu đến độc giả cuộc thảo luận với ChrisW bên dưới. Có thể là việc có được một khu vực dựa trên CRS OTF hoàn toàn không phải là một lỗi; đó là, ít nhất, trong arcgis, nó cũng được sử dụng để cho phép xử lý địa lý hai lớp từ các CRS khác nhau.

Để giải thích về vấn đề trên. Như AndreJ như đề xuất và hiển thị - đây có lẽ là một lỗi trong phiên bản hiện tại của qgis. Tuy nhiên, cần lưu ý rằng vấn đề không phải là khu vực sai, nhưng sự biến đổi nhanh chóng đó ảnh hưởng đến việc tính toán diện tích.

Mục đích của chuyển đổi / chiếu nhanh là để sắp xếp dữ liệu từ các nguồn khác nhau và với CRS khác nhau. Đó là chủ yếu cho mục đích hiển thị. EG arcmap tự động thực hiện phép chiếu khi đang bay trong mọi trường hợp CRS lớp không khớp với CRS của khung dữ liệu.

Arcmap cũng cung cấp khả năng chỉnh sửa dữ liệu khi đang chiếu, nhưng cũng lưu ý rằng: ( nguồn )

Tuy nhiên, điều quan trọng cần lưu ý là một số thao tác chỉnh sửa có thể tạo ra sự cố căn chỉnh hoặc độ chính xác không mong muốn, tùy thuộc vào hệ thống tọa độ được sử dụng.

Các thao tác chỉnh sửa cụ thể có thể gây ra sự cố bao gồm thay đổi hình dạng của các tính năng, gắn vào cạnh hoặc ranh giới của các tính năng hoặc mở rộng và cắt xén các tính năng. Những sự cố này có nhiều khả năng xảy ra khi các tính năng bạn đang chỉnh sửa nằm sát cạnh hoặc vượt ra ngoài phạm vi sử dụng của hệ tọa độ

Điều đó có nghĩa là: việc chuyển đổi nhanh sẽ kém hiệu quả hơn so với việc chỉ chiếu dữ liệu lên một CRS khác (cũng đưa ra các vấn đề của chính nó).

Đã nói rằng không có gì đáng ngạc nhiên khi dựa trên sự biến đổi khi đang bay, một khu vực sai đang được tính toán, nhưng điều đáng ngạc nhiên là thực tế là khi đang bay được kích hoạt ảnh hưởng đến bất kỳ cách tính toán hình học nào. được dựa trên dữ liệu. Do đó, không có vấn đề gì nếu việc chuyển đổi nhanh chóng dựa trên cùng một CRS khác nhau, tính toán diện tích phải giống hệt nhau mỗi lần.

Để thực tế hơn, nếu mục đích của bạn là tính toán khu vực không sử dụng khi đang bay. Nếu bạn có CRS sai, hãy chiếu dữ liệu của bạn.

— dof1985
nguồn

Tôi không chắc chắn về QGIS, nhưng ngược lại với những gì bạn đề cập ở đây ArcGIS thực sự có thể thực hiện Tính toán hình học của mình bằng phép chiếu OTF hoặc phép chiếu hoàn toàn khác nhau tùy thuộc vào phương thức (ví dụ: cột thuộc tính nhấp chuột phải và chọn Tính toán hình học so với trong -code / cuộc gọi máy tính trường của shape.area). Đôi khi có những lựa chọn được đưa ra để sử dụng CRS của 1) dữ liệu / lớp, 2) khung dữ liệu hiện tại, 3) CRS được chỉ định không liên quan đến 1 hoặc 2. Thông thường (một lần nữa, ArcGIS) nếu lựa chọn không được trình bày, nó sẽ được thực hiện trong CRS của khung dữ liệu hiện tại, bất kể dữ liệu là gì (do đó là OTF).

— Chris W

Tôi cũng nên đề cập đến OTF không chỉ dành cho mục đích hiển thị - người ta không phải từ chối một bộ dữ liệu để chạy một công cụ xử lý địa lý cũng sử dụng một bộ dữ liệu với CRS khác; OTF xử lý việc đó. Có một số ngoại lệ này, khi cả hai bộ dữ liệu làm phải trong CRS cùng.

— Chris W

@ChrisW, nếu tôi hiểu chính xác; một số công cụ xử lý địa lý chấp nhận OTF CRS vì nó là CRS của lớp. Do đó, khu vực nhận được dựa trên OTF CRS không nhất thiết là một lỗi. Đúng không? Về Arcgis, chúng ta hãy giả sử WGS84 là OTF; một cuộc gọi như thế nào:!shape.area@meters!

— dof1985

Đúng rồi. Khung dữ liệu và lớp đầu tiên của bạn có thể là WGS84 và bạn có thể thêm lớp thứ hai là NAD83. Lớp thứ hai được OTF chiếu và bạn có thể chạy bất kỳ công cụ bình thường nào như Intersect hoặc Union trên đó và hoạt động diễn ra trong WGS84. Nhận diện tích chắc chắn không phải là một lỗi. Tôi có một khách hàng muốn có dữ liệu trong NAD83, nhưng thông tin yêu cầu các đơn vị tính theo mẫu và tôi làm việc trong CRS dự kiến để nhập thông tin. Tôi thường chỉ thay đổi phép chiếu khung dữ liệu, vùng calc, và sau đó chuyển nó trở lại. Không chắc cuộc gọi đó sẽ được xử lý như thế nào vì tôi nghĩ chuyển đổi đơn vị tách biệt với tính toán.

— Chris W

Tôi có thể xác nhận rằng nó có vẻ là một lỗi.

Tạo một tệp csv với nội dung sau:

E N
600000 200000
700000 200000
700000 300000
600000 300000

Nhập nó dưới dạng văn bản được phân tách bằng EPSG: 21781, cho phép chụp nhanh và vẽ một hình đa giác trên bốn điểm.

Không có OTF, kết quả $area/1000000.0là 10000 mét vuông (điều này rõ ràng là chính xác).

Quay OTF trên , và chọn cùng EPSG: 21.781, bạn sẽ có được 9988,2338 m².

Chọn một CRS khác, như EPSG: 4326, cung cấp 9990.5339 mét vuông, vì phép tính được thực hiện trên một ellipsoid khác (WGS84 thay vì tàu).

Vector --> Geometry Tools --> Export/Add Geometry Columns dường như cung cấp các giá trị chính xác.

Lỗi đã có một số vé: https://issues.qgis.org/issues/10966 và https://issues.qgis.org/issues/12473

— AndreJ
nguồn