Apa praktik terbaik untuk menyimpan fitur geografis (garis, poligon, dan ekuivalen multi-bagiannya) ketika fitur ini menjangkau antimeridian (± 180 ° bujur), dan perlu dikirim ke dan diterima dari aplikasi web klien sebagai GeoJSON?
Saya mulai bekerja pada API web sisi-server dengan dukungan dari database Postgres / PostGIS untuk bekerja dengan trek siklon tropis dan prakiraan angin historis dan perkiraan. Banyak topan di Samudra Pasifik memiliki kecenderungan malang untuk melintasi antimeridian, terkadang beberapa kali dalam masa hidup mereka:
Sebagai orang Selandia Baru yang tinggal di dekat antimeridian, saya telah cukup sering menghadapi masalah ini dalam data regional untuk memiliki beberapa strategi koping, tetapi saya ingin benar-benar mencari tahu apa yang dianggap sebagai praktik terbaik. Sayangnya tidak ada pertanyaan yang diberi tag antimeridian , sehingga sulit untuk mencari pertanyaan terkait. Pertanyaan-pertanyaan yang saya lihat berjuang mengatasi masalah ini semua tampaknya mencari saran yang sangat spesifik untuk aplikasi. Pertanyaan ini secara singkat membahas antimeridian untuk kasus poligon GeoJSON yang membentang di bumi tanpa batas. Pertanyaan ini cukup dekat dengan apa yang saya tanyakan.
Saya perlu menyimpan topan historis dan perkiraan dalam basis data spasial, tetapi saya mengantisipasi bahwa akan ada masalah dengan antimeridian. Misalnya, garis yang dimulai pada garis lintang / garis bujur (0,179)dan berakhir pada (0,-179)bersifat mendua sehubungan dengan arahnya: apakah garis pendek tersebut melintasi antimeridian, atau "membungkus" seluruh planet. Bagaimana seharusnya jalur seperti itu disimpan dalam basis data spasial (khususnya saya bekerja dengan PostGIS tapi saya harap solusinya cukup umum)? Beberapa ide yang saya miliki:
- Jangan ubah geometri fitur dan ubah ambiguitas ke aplikasi klien.
- Pisahkan setiap fitur yang melintasi antimeridian menjadi geometri multi bagian dengan jeda di antimeridian . ( Spesifikasi GeoJSON mendukung bernama CRS .)
- Bekerja dengan proyeksi non-global untuk cekungan siklon yang berbeda atau wilayah lautan yang tidak memiliki diskontinuitas seperti itu
- Mengeksploitasi fakta bahwa topan tidak pernah diamati untuk melakukan perjalanan mengelilingi seluruh planet, menyimpan koordinat topan yang dimulai dalam rentang garis lintang
(90,-90)diimbangi oleh fase 360 ° (menjaga yang lain -180–180 °) - Mengeksploitasi fakta bahwa topan sangat tidak mungkin di selatan ujung selatan Afrika, gunakan penahan pada 30 ° bujur (seperti pada peta di atas).
- Izinkan koordinat untuk melampaui batas EPSG 4326 yang valid , mis.> 180 ° dan <-180 ° untuk fitur apa pun yang melewati antimeridian.
- Pengkodean Delta , seperti pada TopoJSON (mis. Mulai dari
(0,-179)dan kemudian koordinat berikutnya adalah-3lintang barat). Saya tidak tahu apakah atau bagaimana mengimplementasikan ini ketika menyimpan data di PostGIS, tetapi ini adalah solusi yang bagus untuk mengirim data ke aplikasi klien. - Beberapa bentuk notasi vektor atau koordinat kutub. (Tampaknya agak sulit dan tidak biasa.)
Dari semua ini, saya tidak suka ide 2–5 karena mereka tidak generik, tetapi saya suka mereka karena mereka masuk akal untuk aplikasi khusus saya. Untuk aplikasi yang hanya berurusan dengan data di Samudra Pasifik, mereka mungkin masuk akal, jadi saya tidak ingin mendiskon mereka sepenuhnya sebagai opsi.
Gagasan 6 dan 7 diangkat dari blog Tom MacWright , yang layak dibaca tetapi tidak konklusif sehubungan dengan antimeridian.
Ide 4 digunakan oleh GeographicaGS 'GeodesicLinesToGISPython , yang pada gilirannya menggunakan fiona.transform.transform_geomdengan offset antimeridian 360 °. Pada gilirannya, Fiona menggunakan OGR -wrapdateline. Saya kira itu adalah preseden yang sangat solid dan sebenarnya agak generik.
Sehubungan dengan masalah penyimpanan, saya perlu mempertimbangkan bagaimana fitur-fitur seperti itu harus dikirim ke aplikasi klien, dan bagaimana aplikasi saya harus mempertimbangkan data yang diposkan kembali ke sana (misalnya peramal manusia mengubah trek perkiraan badai topan di Pasifik). Format pertukaran mungkin adalah GeoJSON, tetapi tidak harus.
Sayangnya spesifikasi GeoJSON tidak eksplisit tentang masalah antimeridian. Ini dari Wikipedia :
Banyak pustaka perangkat lunak geografis atau format data yang memproyeksikan dunia menjadi persegi panjang; sangat sering persegi panjang ini terpecah persis di meridian ke-180. Ini sering membuat tidak mungkin untuk melakukan tugas-tugas sederhana (seperti mewakili suatu daerah, atau garis) di atas meridian ke-180. Beberapa contoh:
Spesifikasi GeoJSON tidak menyebutkan penanganan meridian ke-180 dalam spesifikasinya, dengan demikian, representasi garis yang melintasi meridian ke-180 dapat juga diartikan sebagai terjadi di seluruh dunia.
Di OpenStreetMap, area (seperti batas Rusia) terbagi pada meridian ke-180.
Bacaan saya adalah bahwa GeoJSON tidak memiliki representasi standar tertentu dari fitur antimeridian-spanning, dan itu sengaja dibiarkan ambigu (geometri multi-bagian mungkin akan menyelesaikan masalah). Demikian pula dalam OpenStreetMap ada pembagian geometri di antimeridian, meskipun saya tidak tahu apakah fitur split tersebut adalah multi-bagian atau sebenarnya merupakan catatan diskrit.
Ini terasa agak bermasalah, terutama dari perspektif membuat kotak pembatas atau permintaan spasial lain yang menjangkau garis ini, tetapi juga dalam mem-parsing dan membersihkan input dan setiap pembaruan untuk fitur geometri. Inilah sebabnya saya mencoba menentukan praktik terbaik yang bisa saya coba patuhi.
