Proj.4 / GDAL / QGIS Transformasi antara CRS yang didefinisikan sama

8

Saya membantu memastikan bahwa perangkat lunak sumber terbuka dapat menangani datum baru Australia dengan tepat, lihat situs web ICSM untuk perincian tentang proyek GDA2020.

Sekarang, QGIS sudah mendapatkan definisi GDA2020 termasuk, melalui GDAL, saya mengerti.

Contoh sistem referensi koordinat GDA2020 adalah ini:

+proj=utm +zone=55 +south +ellps=GRS80 +units=m +no_defs

Dan jika Anda melihat GDA94 CRS, didefinisikan seperti ini:

+proj=utm +zone=55 +south +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs

Seperti yang Anda lihat, ini sangat mirip.

Sekarang, kedua CRS didefinisikan sama persis, tetapi, ada pergeseran koordinat dalam GDA94 ke GDA2020 sekitar 1,5 m ke arah timur laut. (Ada file grid shift dalam format NTv2 yang akan segera siap yang akan memungkinkan transformasi yang tepat, tapi bukan itu pertanyaannya.)

Tapi, jika Anda mengonversi antara GDA94 dan GDA2020 sekarang , menggunakan QGIS, tidak ada perubahan dalam koordinat. Ini pada dasarnya hanya label secara berbeda.

Haruskah transformasi 7 parameter sederhana diimplementasikan dalam Proj.4 atau alat sumber terbuka lainnya yang merupakan transformasi default (meskipun, tidak sempurna) antara GDA94 dan GDA2020?

Atau apakah hanya alat yang akan selalu melakukan perubahan?

Bagaimana ini harus ditangani?

(Dan saya hanya ingin mencatat lagi bahwa mengubah menggunakan kisi adalah ideal, dan itu ditangani dalam beberapa cara termasuk plugin QGIS ini .)

qgis coordinate-system gdal proj gda2020 Alex Leith
sumber
1
Apakah Anda pikir mungkin lebih baik menunda sampai transformasi NTv2 tersedia, seperti transformasi dari AGD66 ke GDA94 (tetapi lebih kecil), jika Anda akan melakukan sesuatu lakukan dengan benar atau tidak sama sekali ... kalau tidak Anda akan berakhir dengan koordinat yang didefinisikan ulang di tempat yang salah, tidak banyak tetapi masih salah. Mempertimbangkan GDA2020 bukan datum statis tentunya harus ada tanggal yang ditentukan dalam CRS tentang kapan transformasi koordinat diterapkan.
Michael Stimson
Sudahkah otoritas Australia memberikan parameter itu? Jika mereka memiliki proyek Proj4 dapat memasukkan mereka sebagai parameter + towgs84 tetapi parameter harus memiliki status resmi. Pengguna dapat menggunakan + towgs84 secara alami sesuai keinginan.
user30184
Hai teman-teman, pertama, parameter + towgs84 harus 0,0,0,0,0,0,0, dari pemahaman saya, karena perbedaan antara dua datum praktis tidak ada. Dan transformasi NTv2 hampir tersedia, dan bukan yang saya tanyakan. Mungkin Anda benar, @MichaelStimson, dalam melakukan transformasi TIDAK lebih baik daripada melakukan yang tidak sempurna.
Alex Leith

Jawaban:

4

Jika Anda mencari di database EPSG untuk GDA94CoordinateTransformation, Anda mendapatkan:

  • Kode transformasi EPSG:1150GDA94 ke WGS84 (1) yang memiliki nilai semua-nol
  • Kode transformasi EPSG:8048GDA94 ke GDA2020 (1) dengan 7 nilai yang diberikan oleh @ user30184

Jadi adalah aman untuk mengambil mereka untuk GDA2020 ke WGS84 (mengurus tanda dan unit!) Sampai pergeseran grid baru diterbitkan. Itu akan mendapatkan nomor kode transformasi baru.

Saat ini terdapat kode Transformasi EPSG:8049ITRF2014 ke GDA2020 (1) yang menyatakan bahwa keduanya sama untuk saat ini, dengan nilai kenaikan tahunan. Jadi Anda bisa menggunakan kerangka waktu ITRF juga.

AndreJ
sumber
Aha, terima kasih @AndreJ, itu adalah bagian pertama dari pertanyaan saya. Dan sekarang, apa yang diperlukan untuk transformasi ini untuk digunakan sebagai standar dalam, katakanlah, QGIS?
Alex Leith
Anda perlu memasang CRS khusus untuk setiap CRS basec GDA2020. Perhatikan bahwa nilai shift dalam mm, sedangkan PROJ.4 mengharapkan meter. Anda dapat mengedit srs.db dari QGIS juga, tanpa jaminan apa pun.
AndreJ
ITRF2014 dan GDA2020 akan hanya menjadi sesaat sama pada Jan 1, 2020. Sama seperti GDA94 itu sebentar selaras dengan ITRF92 pada tahun 1994. Jika Anda ingin mengubah suatu akurat untuk setiap saat tetapi zaman yang 2020,0 maka Anda perlu melakukan 4D transformasi yang memperhitungkan parameter drift tergantung waktu. Transformasi yang didefinisikan dalam EPSG: 8049 bergantung pada waktu, dan versi pro.4 terbaru dapat memperhitungkan perbedaan antara zaman penyelarasan datum dan kapan data Anda ditangkap.
Rob
2

Kamu bertanya:

Haruskah transformasi 7 parameter sederhana diimplementasikan dalam Proj.4 atau alat sumber terbuka lainnya yang merupakan transformasi default (meskipun, tidak sempurna) antara GDA94 dan GDA2020? Atau apakah hanya alat yang akan selalu melakukan perubahan? Bagaimana ini harus ditangani?

FAQ di http://www.icsm.gov.au/gda2020/faq.html menginformasikan:

Produk-produk berikut akan tersedia:

  • Transformasi 2D dan file grid distorsi dalam format Canadian National Transformations versi 2 (NTv2) yang banyak digunakan
  • 7 parameter kesamaan (Helmet) transformasi
  • File kotak transformasi 3D - format belum ditentukan.

Nilai-nilai yang mendukung transformasi kumpulan data antara GDA2020 dan ITRF2014 menggunakan baik model gerakan pelat atau 14 transformasi kesamaan parameter juga akan diterbitkan.

Informasi ini akan diberikan langsung ke EPSG Geodetic Parameter Registry yang dirujuk oleh penyedia perangkat lunak dan perangkat keras spasial di seluruh dunia sebelum memasukkan parameter transformasi ke dalam perangkat lunak dan firmware.

Setelah ICSM mempublikasikan 7 parameter, parameter transformasi kesamaan Anda dapat mulai menggunakannya sebagai

+ proj = utm + zone = 55 + selatan + ellps = GRS80 + towgs84 = [parameter baru] + unit = m + no_defs

Saya sepertinya sudah diterbitkan di http://www.icsm.gov.au/gda2020/InterimReleaseNoteV1.0.pdf .

61.55, -10.87, -40.19, -9.994, -39.4924, -32.7221, -32.8979

Anda dapat mencoba dengan parameter + towgs84 ini tetapi saya ingat bahwa Proj.4 mungkin menginginkan beberapa parameter dengan tanda terbalik.

Membuat tiket Proj.4 ketika parameter tersedia secara resmi dapat mempercepat proses dengan Proj.4 tetapi ketika database EPSG diperbarui dan Proj.4 mulai menggunakan database baru itu, perubahan dapat terjadi secara otomatis. Tergantung sedikit pada bagaimana GDA2020 akan diimplementasikan dalam database EPSG dan apakah algoritma baru diperlukan atau jika itu hanya pertanyaan tentang menambahkan parameter towgs84.

pengguna30184
sumber
Anda mungkin harus menunggu beberapa saat sampai perubahan basis data EPSG menemukan jalannya ke GDAL dan PROJ.4. GDAL saat ini (2.2.2) berdasarkan pada database EPSG v9.0 dari Des 2016 trac.osgeo.org/gdal/ticket/6772 dan tidak akan diperbarui hingga v2.3.0. PROJ.4 masih lebih lama: github.com/OSGeo/proj.4/issues/477 akan ada di rilis berikutnya.
AndreJ
Hai @ user30184, saya tidak berpikir parameter toWGS84 digunakan untuk tujuan ini. Situs web Proj.4 mengatakan bahwa ini adalah parameter untuk mengubah koordinat pada satu datum menjadi datum WGS84, dan dengan case GDA94 dan GDA2020, datum sama seperti untuk WGS84 (untuk semua maksud dan tujuan), lihat: proj.maptools .org / gen_parms.html . Apa yang diperlukan adalah cara untuk mengubah antara dua CRS geodetik yang didefinisikan dengan ellipsoid referensi yang sama, saya pikir. Dan saya perhatikan bahwa definisi GDA2020 ada dalam registri EPSG dan dalam alat-alat seperti QGIS sudah, jadi tidak perlu menunggu.
Alex Leith
Proj.4 menggunakan WGS84 sebagai datum sementara. Jika Anda memiliki parameter + wgS84 di satu sisi tetapi tidak di sisi lain, Anda akan mendapatkan pergeseran datum. Coba dengan + towgs84 dan laporkan hasil Anda.
user30184
Hai, saya kira apa yang saya harapkan untuk dicapai dari ini adalah memastikan bahwa parameter transformasi ini (yang, seperti yang ditunjukkan oleh @AndreJ adalah bagian dari basis data EPSG) digunakan secara default di alat sumber terbuka. Saya akan membaca ...
Alex Leith
1

TLDR: Mereka tidak sama. Kesetaraan yang dilaporkan adalah hasil dari perkiraan dan hanya berlaku dalam keadaan terbatas. Koordinat GDA94 / 2020 didefinisikan pada data yang berbeda dan kerangka referensi. Transformasi yang tepat di antara mereka tergantung pada tingkat akurasi yang diinginkan.

Masalahnya di sini adalah asumsi dalam pertanyaan bahwa proj.4 benar melaporkan dua CRS (sistem referensi koordinat) sebagai sama. Mereka tidak. String proj.4 yang dikutip bukan definisi CRS. Mereka dihasilkan dari definisi CRS, dan string proj.4 bukan gambaran lengkap. Definisi registri EPSG memberi kami informasi tambahan yang kami butuhkan untuk memahami apa yang sebenarnya terjadi.

Ini berasal dari pandangan dunia bahwa WGS-84 adalah datum global 'dan' proj historis.4 telah menggunakannya sebagai perantara ketika mengkonversi antara datum. Masalahnya, WGS-84 akan didefinisikan ulang setiap beberapa tahun ( kami berada di G1762 sekarang, disejajarkan dengan ITRF-08 ) karena diselaraskan kembali dengan perubahan dalam kerangka referensi ITRF, dari mana GDA juga diturunkan.

Ini telah menyebabkan pintasan dan asumsi ini dimasukkan ke dalam perilaku proj, meskipun dalam versi terbaru ini mulai berubah.

Melacak implikasi perubahan pada kerangka referensi, dan ketika mereka berubah bukanlah masalah besar sementara GPS konsumen memiliki ketelitian> 5 juta tetapi waktu berubah dan akurasi sub-meter membutuhkan alat yang memperhitungkannya dengan benar.

Jadi, untuk menjawab pertanyaan tersebut, kita perlu melacak kerangka data dan referensi apa yang menjadi dasar GDA94 dan GDA2020 CRS dan kemudian melihat transformasi apa yang tersedia.

  • EPSG:7844 GDA2020 2D Geografis CRS (Lat / Lon), dari
  • EPSG:7843 GDA2020 3D Geographic CRS (L / L / H), dari
  • EPSG:7842 GDA2020 3D Geocentric (ECEF X / Y / Z), yang semuanya digunakan
  • EPSG: 1168 (datum) - Datum geosentris Australia, 2020

EPSG: 1168 mendefinisikan kerangka referensi jangkar:

  • Definisi Jangkar: ITRF2014 pada zaman 2020.0
  • Realisasi Epoch: 2020-01-01

Jika Anda melakukan hal yang sama untuk GDA94 Anda akan melihat bahwa kerangka referensi adalah ITRF92, selaras pada 01/01/1994.

Jika mentransformasikan antara data ITRF02 / 14 dan GDA94 / GDA2020, datum diselaraskan, dan transformasi di antara mereka null hanya pada tanggal penyelarasan zaman. Pada dasarnya itulah yang dikatakan oleh string-string itu. Untuk kenyamanan, kami biasanya tidak suka harus terus-menerus mengubah koordinat yang kami simpan, jadi lebih mudah untuk melangkah mengubah pergeseran di antara mereka setiap beberapa tahun dan menerima tingkat kesalahan.

Untuk sebagian besar aplikasi yang membutuhkan akurasi> 1m, itu cukup baik.

Tetapi kenyataan tidak melangkah berubah setiap beberapa tahun dan jika kita menginginkan transformasi yang lebih akurat, kita perlu mempertimbangkan penyimpangan jarak yang tergantung waktu dari datum sebelum / setelah penyelarasannya. Ini adalah transformasi 4D daripada 3D.

Transformasi antara GDA2020 dan WGS-84 atau ITRF2014 dijelaskan dalam:

  1. GDA2020 ke WGS 84 (G1762) (1) - EPSG: 8448
  2. ITRF2014 ke GDA2020 (1) - EPSG: 8049

Jika mentransformasikan antara GDA94 dan GDA2020, semuanya lebih sederhana karena kita hanya perlu mengetahui perbedaan antara kerangka referensi. Semacam. Ada lebih dari satu, dan yang benar untuk digunakan tergantung pada kapan, bagaimana dan di mana data dirujuk ke GDA94. Ini merupakan upaya untuk menghilangkan kesalahan karena metode yang kurang disempurnakan yang digunakan di tahun 90-an.

Ini adalah:

Untuk memahami dalam keadaan apa ini harus digunakan, baca manual teknis GDA2020

rampok
sumber
0

Membangun jawaban sebelumnya definisi proj4 terlihat seperti ini:

+proj=longlat +ellps=GRS80 +towgs84=-0.06155,0.01087,0.04019,-0.0394924,-0.0327221,-0.03289790,0.009994 +no_defs

Anda kemudian dapat menggunakan ini di salah satu zona grid proyeksi standar dengan hanya menambahkan parameter towgs84. misalnya

+proj=utm +zone=55 +south +ellps=GRS80 +towgs84=-0.06155,0.01087,0.04019,-0.0394924,-0.0327221,-0.03289790,0.009994 +units=m +no_defs

Untuk mendapatkan angka yang tepat dari bagian 3.1 dari spesifikasi, pertama-tama Anda membalikkan tanda parameter rotasi (seperti yang dibahas dalam bagian 2.2.1), tetapi kemudian membalikkan semuanya karena parameter dalam spesifikasi adalah transformasi dari WGS / GDA94 dan kami ingin transformasi ke WGS untuk definisi proj4. Jadi pada dasarnya semuanya kecuali rotasi dalam spesifikasi memiliki tanda terbalik.

Satu-satunya hal lain yang harus diperhatikan adalah untuk proj4 skalanya adalah parameter terakhir.

Purist akan menyarankan menggunakan pendekatan grid shift NtV2 tetapi file-file ini sangat besar dan saya telah menemukan bahwa di atas memberikan akurasi lebih dari 5cm menggunakan data sampel untuk Victoria. Saya juga menginginkan solusi yang akan bekerja dengan proj4js.

JohnGom
sumber