Perhitungan area QGIS berbeda ketika transformasi CRS on the fly diaktifkan

Ketika saya membuka QGIS, menambahkan layer, dan menghitung area shapefile melalui kalkulator lapangan, saya mendapatkan area yang berbeda dari ketika saya membuka QGIS dan memeriksa "Aktifkan transformasi CRS dengan cepat" dan hitung area. Ini meskipun memastikan bahwa proyek dan lapisan memiliki sistem Koordinat yang sama (nomor EPSG yang sama). Apa yang saya lakukan salah?

Saya memiliki shapefile dengan perhitungan area yang dibuat dengan ArcGIS (bukan saya, data diserahkan kepada saya dan saya tidak memiliki petunjuk yang CRS area dihitung dengan ArcGIS). Lapisan shapefile CRS adalah EPSG: 21781 (Swiss). Di QGIS, jika saya tidak mengubah pengaturan OTF dan meninggalkan proyek CRS sebagai EPSG: 4326 (WGS84) saya mendapatkan nilai yang sama dengan nilai area ArcGIS. Namun, jika saya mengubah OTF sebelum menambahkan layer ke EPSG: 21781 saya mendapatkan nilai area yang berbeda. Seperti yang saya pahami ini menunjukkan bahwa Area ArcGIS dihitung dengan CRS EPSG: 4326.

Alur kerja pertama:

buka QGIS
proyek CRS: EPSG 4326
tambahkan layer
proyek CRS beradaptasi secara otomatis dan sekarang EPSG 21781
menghitung $ area dengan kalkulator bidang

Alur kerja kedua:

buka QGIS
proyek CRS: EPSG 4326
Aktifkan OTF, atur proyek CRS ke EPSG 21781
tambahkan layer
menghitung $ area dengan kalkulator bidang

Langkah 5 dari alur kerja pertama dan kedua JANGAN menghasilkan area yang sama.

qgis coordinate-system area

— kalakaru
sumber

dapatkah Anda memberikan contoh alur kerja dan alat yang Anda gunakan; Saya sudah mencobanya dengan on-the-fly diaktifkan dan dinonaktifkan di WGS84 dan memberi area yang sama. Itu menggunakan $areadalam kalkulator yang diajukan. Singkatnya, on-the-fly mempengaruhi bagaimana geometri ditampilkan tanpa mengubah data de-facto. Dengan demikian, kemungkinan besar kesalahan tersebut disebabkan oleh alur kerja.

— dof1985

Apakah $ area menghitung area berdasarkan lapisan atau sistem mengoordinasikan proyek?

— kalakaru

Saya telah memeriksa dan tampaknya memberikan area dalam unit OTF; namun saya cukup yakin ini menggunakan geometri dari layer itu sendiri

— dof1985

Itu mungkin menjadi akar masalah saya. Saya memiliki shapefile dengan Perhitungan Area yang dibuat dengan ArcGis (bukan saya, data diserahkan kepada saya dan saya tidak memiliki petunjuk untuk mana CRS area dihitung dengan ArcGIS). Layer shapefiley CRS adalah EPSG: 21781 (Swiss). Jika saya tidak mengubah pengaturan OTF dan meninggalkan proyek CRS sebagai EPSG: 4326 (WGS84) saya mendapatkan nilai yang sama dengan nilai Area ArcGis. Namun, jika saya mengubah OTF sebelum menambahkan layer ke EPSG: 21781 saya mendapatkan nilai area yang berbeda. Seperti yang saya pahami ini menunjukkan bahwa Area ArcGIS dihitung dengan CRS EPSG: 4326.

— kalakaru

Sejauh yang saya tahu Arcgis dapat menghitung geometri dalam banyak cara. Menggunakan ekspresi python kalkulator bidang !shape.area!harus memberikan area sesuai dengan layer crs; daripada menghitung geometri mungkin bekerja berbeda. Jadi sulit untuk mengatakan, persis apa yang telah dilakukan di arcgis, namun jika Anda mendapatkan hasil yang sama, misalnya derajat dan bukan meter, itu berarti bahwa perhitungan area memang didasarkan pada ESPG: 4326.

— dof1985

Jawaban:

EDIT - Penafian: Saya ingin merujuk pembaca ke diskusi dengan ChrisW di bawah ini. Mungkin saja mendapatkan area berdasarkan CRS OTF bukanlah bug sama sekali; paling tidak, di arcgis juga digunakan untuk memungkinkan geoprosesing dua lapisan dari CRS yang berbeda.

Untuk menguraikan masalah di atas. Seperti yang disarankan dan ditunjukkan oleh AndreJ - ini mungkin adalah bug dalam versi qgis saat ini. Namun perlu dicatat bahwa masalahnya bukan pada area yang salah, tetapi transformasi on-the-fly tetap mempengaruhi perhitungan area.

Tujuan transformasi / proyeksi on-the-fly adalah untuk menyelaraskan data dari sumber yang berbeda dan dengan CRS yang berbeda. Itu terutama untuk tujuan tampilan. EG arcmap secara otomatis melakukan proyeksi on-the-fly dalam hal apapun layer CRS tidak cocok dengan frame data CRS.

Arcmap juga menyediakan kemungkinan untuk mengedit data saat diproyeksikan sambil jalan, tetapi juga mencatat bahwa: ( sumber )

Namun, penting untuk dicatat bahwa operasi penyuntingan tertentu dapat menghasilkan masalah penyelarasan atau akurasi yang tidak terduga, tergantung pada sistem koordinat yang digunakan.

Operasi pengeditan khusus yang dapat menyebabkan masalah termasuk mengubah bentuk fitur, gertakan ke tepi atau batas fitur, atau memperluas dan memotong fitur. Masalah-masalah ini lebih mungkin terjadi ketika fitur yang Anda edit dekat dengan tepi atau di luar area penggunaan sistem koordinat

Dengan kata lain: transformasi on the fly kurang akurat daripada hanya memproyeksikan data ke CRS yang berbeda (yang juga memperkenalkan masalahnya sendiri).

Setelah mengatakan bahwa tidak mengherankan bahwa berdasarkan transformasi on-the-fly area yang salah sedang dihitung, namun mengejutkan bahwa fakta bahwa on-the-fly diaktifkan memengaruhi perhitungan geometri, yang seharusnya didasarkan pada data. Dengan demikian, tidak masalah jika transformasi on-the-fly didasarkan pada CRS yang sama atau berbeda, perhitungan area harus sama setiap waktu.

Agar lebih praktis, jika tujuan Anda adalah menghitung area, jangan gunakan saat bepergian. Jika Anda salah CRS, proyeksikan data Anda.

— dof1985
sumber

Saya tidak yakin tentang QGIS, tetapi dalam beberapa kontras dengan apa yang Anda sebutkan di sini, ArcGIS sebenarnya dapat melakukan Calculate Geometry-nya menggunakan proyeksi OTF atau proyeksi yang sama sekali berbeda tergantung pada metode (mis. Kolom atribut klik kanan dan pilih Calculate Geometry vs an in -kode / bidang panggilan kalkulator shape.area). Kadang-kadang ada pilihan yang diberikan untuk menggunakan CRS dari 1) data / layer, 2) dataframe saat ini, 3) CRS yang ditentukan tidak terkait dengan 1 atau 2. Biasanya (sekali lagi, ArcGIS) jika pilihan tidak disajikan itu akan dilakukan dalam CRS dataframe saat ini, terlepas dari apa data itu (karenanya OTF).

— Chris W

Saya juga harus menyebutkan OTF bukan hanya untuk tujuan tampilan - orang tidak harus memproyeksikan ulang dataset untuk menjalankan alat geoprocessing yang juga menggunakan dataset dengan CRS yang berbeda; OTF menanganinya. Ada beberapa pengecualian untuk ini, ketika kedua dataset yang harus di CRS yang sama.

— Chris W

@ Chris, jika saya mengerti dengan benar; beberapa alat geoproses menerima OTF CRS karena itu adalah lapisan CRS. Jadi mendapatkan area berdasarkan OTF CRS tidak harus berupa bug. Apakah itu benar? Mengenai Arcgis, mari kita asumsikan WGS84 sebagai OTF; bagaimana dengan panggilan seperti:!shape.area@meters!

— dof1985

Itu benar. Kerangka data dan lapisan pertama Anda bisa WGS84, dan Anda bisa menambahkan lapisan kedua yaitu NAD83. Lapisan kedua diproyeksikan OTF, dan Anda dapat menjalankan alat normal seperti Intersect atau Union di atasnya dan operasi berlangsung di WGS84. Mendapatkan area jelas bukan bug. Saya memiliki klien yang menginginkan data di NAD83, tetapi info tersebut membutuhkan unit dalam hektar dan bahwa saya bekerja di CRS yang diproyeksikan untuk memasukkan info. Saya biasanya hanya mengubah proyeksi dataframe, area kalk, dan kemudian mengubahnya kembali. Tidak yakin bagaimana panggilan itu akan ditangani karena saya pikir konversi unit terpisah dari perhitungan.

— Chris W

Saya dapat mengonfirmasi bahwa itu sepertinya bug.

Buat file csv dengan konten berikut:

E N
600000 200000
700000 200000
700000 300000
600000 300000

Impor sebagai teks terbatas dengan EPSG: 21781, aktifkan gertakan dan gambar poligon di keempat titik.

Tanpa OTF, hasilnya $area/1000000.0adalah 10000 m² (yang jelas benar).

Menghidupkan OTF pada , dan memilih EPSG yang sama: 21.781, Anda mendapatkan 9988,2338 m².

Memilih CRS yang berbeda, seperti EPSG: 4326, menghasilkan 9990.5339 m², karena perhitungan dilakukan pada ellipsoid yang berbeda (WGS84, bukan bessel).

Vector --> Geometry Tools --> Export/Add Geometry Columns tampaknya memberikan nilai yang benar.

Bug tersebut sudah memiliki beberapa tiket: https://issues.qgis.org/issues/10966 dan https://issues.qgis.org/issues/12473

— AndreJ
sumber