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

24

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:

masukkan deskripsi gambar di sini

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 , 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.

alphabetasoup
sumber
1
Itu pertanyaan yang sangat bagus, sebelumnya saya telah menggunakan sistem koordinat buatan tangan mulai dari 90 derajat tetapi saya hanya mementingkan area yang sangat kecil. Sebenarnya tidak ada yang bisa 'dibungkus' dengan benar; Saya menduga itu karena tidak ada daratan (yang penting) yang mengangkangi 180 dan sangat sedikit orang yang harus memetakannya seluruh masalah menerima sedikit perhatian.
Michael Stimson
Pertanyaan bagus Saya pikir Anda menggoda nasib dengan poin 4, meskipun dalam praktiknya tidak ada alasan mengapa koordinat tidak dapat melampaui 360, menggunakan mod untuk memulihkan mereka. Delta terdengar seperti solusi yang paling bisa dikembangkan, dan bahkan bisa memiliki beberapa manfaat dalam hal kompresi data, tetapi, seperti yang Anda katakan, mengalihkan tanggung jawab kepada klien.
John Powell
Beberapa komentar tentang GeoJSON sekarang kedaluwarsa sejak 1.0 RC. Salah satu contoh adalah bahwa definisi CRS di GeoJSON sudah usang ( sgillies.net//2014/08/06/pruning-crs-from-geojson.html ). Saya akan mengedit ini pada akhirnya.
alphabetasoup

Jawaban:

7

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.

Mike T
sumber
2
Salah satu batasannya adalah geografi tidak boleh lebih lebar / lebih dari 180º (lihat FAQ lanjutan ). Namun, Anda bisa menggunakan aturan ini untuk vertexes dan melakukan sesuatu yang konyol seperti ini : LINESTRING(179.9 -17, 60 -16.9, -60 -16.8, -179.8 -16.7), yang semacam-membungkus di sekitar.
Mike T
0

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 tangkapan layar dari Google Earth Pro

cffk
sumber
Saya tidak tahu banyak tentang Google Earth, jadi saya tidak tahu cara mengaktifkan mode outline. Tetapi di sini Anda memiliki poligon yang valid yang membentang antimeridian dan dalam gambar Anda, kami melihat bahwa Google Earth gagal merendernya dengan benar: jadi bagaimana bukti ini bahwa meneruskan ambiguitas ke aplikasi klien adalah praktik terbaik jika Google Earth tidak dapat mengatasi saya t? Kebetulan QGIS memberi saya render masalah dengan poligon ini di SRID 4326, tetapi tidak jika saya memperkenalkan garis di antimeridian (kecuali ... yah baris). Dokumen asli menjadi cemerlang jika saya menggunakan proyeksi Antartika Stereografis.
alphabetasoup
Cukup adil. Namun, mengingat koordinat kml terbatas pada lintang dan bujur, tidak ada yang dapat Anda, pengguna, lakukan untuk membantu Google Earth dalam contoh khusus ini. Tanggung jawab ada pada pengelola Google Earth untuk memperbaiki masalah ini di sisi klien. (Sayangnya, mereka menunjukkan sedikit kecenderungan untuk melakukannya!)
cffk