Praktik terbaik untuk database dan API dengan data geografis yang mencakup antimeridian

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:

1. Jangan ubah geometri fitur dan ubah ambiguitas ke aplikasi klien.
2. Pisahkan setiap fitur yang melintasi antimeridian menjadi geometri multi bagian dengan jeda di antimeridian . ( Spesifikasi GeoJSON mendukung bernama CRS .)
3. Bekerja dengan proyeksi non-global untuk cekungan siklon yang berbeda atau wilayah lautan yang tidak memiliki diskontinuitas seperti itu
4. 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 °)
5. Mengeksploitasi fakta bahwa topan sangat tidak mungkin di selatan ujung selatan Afrika, gunakan penahan pada 30 ° bujur (seperti pada peta di atas).
6. Izinkan koordinat untuk melampaui batas EPSG 4326 yang valid , mis.> 180 ° dan <-180 ° untuk fitur apa pun yang melewati antimeridian.
7. 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.
8. 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.

Berbicara murni dari sudut pandang penyimpanan dan analisis data, geographytipe PostGIS dirancang dengan mempertimbangkan antimeridian (di antara beberapa tujuan desain). Ada beberapa fungsi yang dirancang khusus untuk geographyjenis ini .

Misalnya, pertimbangkan LineString melintasi Taveuni, Fiji ( dipetakan dengan Great Circle Mapper ), yang mengangkangi antimeridian:

SELECT ST_Length('LINESTRING(179.9 -17, -179.8 -16.7)'::geography);

Panjang geodesik ini sekitar 46 km. Demikian pula, ST_Area akan bekerja dengan benar pada sebuah Poligon pulau, bahkan dengan koordinat bujur melompat antara +179 dan -179.

Casting EPSG: 4326 geometryke geographytipe juga menormalkan koordinat, misalnya bujur koordinat terakhir adalah> 180:

SELECT ST_AsGeoJSON('LINESTRING (179.9 -17, 180.2 -16.7)'::geography);

NOTICE:  Coordinate values were coerced into range [-180 -90, 180 90] for GEOGRAPHY
                           st_asgeojson
------------------------------------------------------------------
 {"type":"LineString","coordinates":[[179.9,-17],[-179.8,-16.7]]}

dikonversi kembali ke geographyjenis yang sama persis pada contoh pertama, tetapi sekarang dengan keluaran GeoJSON. Anda dapat memilih untuk mengabaikan PEMBERITAHUAN (atau mis. SET client_min_messages TO WARNING;), Dan mengonversi semua jenis geometri yang tampak lucu sebagai geographyjenis.

Menampilkan geographyjenis pada peta di luar PostGIS adalah cerita yang berbeda, dan mudah-mudahan jawaban yang lebih baik akan menyentuh aspek ini.

Tentunya, jawaban yang lebih disukai adalah (1), yaitu, memiliki klien melakukan "hal yang benar". Kasus yang baik untuk dipertimbangkan adalah poligon yang mewakili benua Antartika diperkirakan oleh file kml ini

<kml> <Folder> <name>Antarctica</name> <Placemark> <name>Antarctica</name> <Polygon> <tessellate>1</tessellate> <outerBoundaryIs> <LinearRing> <coordinates> -58,-63.1,0 -74,-72.9,0 -102,-71.9,0 -102,-74.9,0 -131,-74.3,0 -163,-77.5,0 163,-77.4,0 172,-71.7,0 140,-65.9,0 113,-65.7,0 88,-66.6,0 59,-66.9,0 25,-69.8,0 -4,-70,0 -14,-71,0 -33,-77.3,0 -46,-77.9,0 -61,-74.7,0 -58,-63.1,0 </coordinates> </LinearRing> </outerBoundaryIs> </Polygon> </Placemark> </Folder> </kml>

Pengkodean atau pemindahan delta tempat break garis bujur terjadi tidak akan membantu dengan data seperti ini. Bekerja dengan proyeksi khusus untuk Antartika akan berhasil, tetapi ini bukan solusi umum.

Hebatnya, Google Earth Pro tidak menampilkan poligon ini dengan benar (kecuali jika Anda menggunakan mode "garis besar"). Lihat disini