Antimeridyeni kapsayan coğrafi verilere sahip veritabanları ve API'ler için en iyi yöntemler

Bu özellikler antimeridyeni (± 180 ° boylam) kapsadığında ve GeoJSON olarak müşterinin web uygulamalarına gönderilmeli ve bunlardan alınması gerektiğinde coğrafi özellikleri (çizgiler, çokgenler ve çok parçalı eşdeğerleri) depolamak için en iyi uygulama hangisidir?

Tarihi ve tahmini tropik siklon izleri ve rüzgar yarıçapı ile çalışmak için Postgres / PostGIS veritabanından destek alarak sunucu tarafında bir web API'sinde çalışmaya başlıyorum. Pasifik Okyanusu'ndaki birçok siklon antimerideri geçme şanssızlığına meyillidir, bazen yaşamları boyunca defalarca:

Antimeridyen yakınında yaşayan bir Yeni Zelandalı olarak, bu sorunla bazı başa çıkma stratejilerine sahip olmak için bölgesel verilerde yeterince sık rastladım, ancak gerçekten en iyi uygulama olarak kabul edilen şeyin ne olduğunu bulmak istiyorum. Ne yazık ki antimeridyen etiketli bir soru yok , bu nedenle ilgili soruları aramak zor. Bu problemle mücadele ederken gördüğüm soruların hepsi uygulamaya özel tavsiyelerde bulunmak istiyor gibi görünüyor. Bu soru , sınır tanımayan dünya çapında bir GeoJSON poligonunun durumundaki antimeridyeni kısaca tartışıyor. Bu soru sorduğum şeye oldukça yakın.

Tarihsel ve öngörülen siklonları mekansal bir veritabanında saklamam gerekiyor, ancak antimeridyen ile ilgili sorunlar olacağını tahmin ediyorum. Örneğin, enlem / boylamla başlayan (0,179)ve biten bir çizgi (0,-179), yönüne göre belirsizdir: antimeridyen boyunca kısa bir yoldan geçip geçmediği veya tüm gezegenin etrafına "sarılmış" olup olmadığı. Böyle bir yol mekansal bir veritabanında nasıl saklanmalıdır (özellikle PostGIS ile çalışıyorum ancak çözümün yeterince genel olduğunu umuyorum)? Sahip olduğum bazı fikirler:

1. Geometri özelliklerinde hiçbir değişiklik yapmayın ve belirsizliği müşteri uygulamalarına kaydırın.
2. Antimerideri geçen, antimerideri kopartan çok parçalı bir geometriye dönüştüren tüm özellikleri bölün . ( GeoJSON spesifikasyonu, adlandırılmış CRS'leri destekler .)
3. Süreksizliği olmayan farklı siklon havzaları veya okyanus bölgeleri için küresel olmayan projeksiyonlarla çalışın
4. Bir siklonun tüm gezegenin etrafında hareket ettiği gözlemlenmemiş olduğu gerçeğinden yararlanarak, enlem aralığında başlayan (90,-90) 360 ° 'lik bir faz ile dengelenen enlem aralığında başlayan siklonların koordinatlarını saklayın (diğerlerini -180-180 °' de saklayın)
5. Bir siklonun Afrika'nın güney ucunun son derece düşük bir ihtimal olduğu gerçeğinden yararlanarak , 30 ° boyunda bir mola kullanın (yukarıdaki haritadaki gibi).
6. Antimeridyeni geçen tüm özellikler için koordinatların geçerli EPSG 4326 aralığının ötesine geçmesine izin verin , örn.>> 180 ° ve <-180 °.
7. Delta kodlaması , TopoJSON'daki gibi (örneğin başlangıç (0,-179)ve sonraki koordinat -3enlem batıdır ). PostGIS’te veri depolarken bunun nasıl uygulanacağına veya uygulanacağına dair hiçbir fikrim yok, ancak bu, istemci uygulamalarına veri göndermek için mükemmel bir çözüm.
8. Bazı vektör notasyonları veya kutupsal koordinatlar. (Oldukça zor ve sıradışı görünüyor.)

Bunlardan 2-5 arası fikirlerden hoşlanmıyorum, çünkü bunlar genel değiller ama kendi uygulamalarım için bir şeyler ifade ettikleri için onları sevdim. Sadece Pasifik Okyanusu'ndaki verilerle ilgilenen uygulamalar için çok mantıklı olabilirler, bu yüzden onları tamamen seçenek olarak değerlendirmek istemiyorum.

6 ve 7 numaralı fikirler Tom MacWright'ın okumaya değer ancak antimeridyenle ilgili olarak kesin olmayan bir blogundan kalktı.

Fikir 4, sırasıyla 360 ° antimoneri ofset kullanan GeographicaGS 'GeodesicLinesToGISPython tarafından kullanılır fiona.transform.transform_geom. Buna karşılık, Fiona OGR kullanıyor -wrapdateline. Sanırım bu çok sağlam bir emsal ve aslında oldukça genel.

Depolama konusu ile bağlantılı olarak, bu özelliklerin müşteri uygulamalarına nasıl gönderilmesi gerektiğini ve uygulamamın kendisine geri gönderilen verileri nasıl dikkate alması gerektiğini düşünmem gerekiyor (örneğin Pasifik'teki bir siklonun tahmin izini değiştiren bir insan tahmincisi). Değişim formatı muhtemelen GeoJSON olacaktır, fakat böyle olmak zorunda değil.

Ne yazık ki GeoJSON spesifikasyonu antimeridyen konularında açık değildir. Bu Wikipedia'dan :

Birçok coğrafi yazılım kütüphanesi veya veri formatı dünyayı bir dikdörtgene yansıtır; Çok sık bu dikdörtgen tam 180. meridyen ayrılır. Bu genellikle 180'inci meridyen üzerinden basit işler (bir alanı veya bir çizgiyi temsil etmek gibi) yapmayı imkansız hale getirir. Bazı örnekler:

• GeoJSON spesifikasyonu, 180'inci meridyenin spesifikasyonunda ele alınmasından bahsetmemektedir, çünkü 180'inci meridyeni geçen çizgilerin temsili, dünyanın dört bir yanından olduğu gibi yorumlanabilir.

• OpenStreetMap'te alanlar (Rusya'nın sınırı gibi) 180'inci meridyende bölünmüştür.

Benim okumam GeoJSON'un antimeridyen-yayılma özelliklerini gösteren özel bir standart gösterimi olmadığı ve kasıtlı olarak belirsiz bırakıldığı (çok parçalı geometriler sorunu çözecektir). OpenStreetMap'te de benzer şekilde antimeridyende geometri bölümleri vardır, ancak böylesi bölünmüş özelliklerin çok parçalı mı yoksa gerçekte ayrı kayıtlar mı olduğunu bilmiyorum.

Bu, özellikle sınırlayıcı kutu veya bu çizgiyi kapsayan diğer uzamsal istekler oluşturma perspektifinden, aynı zamanda girdiyi ve özellik geometrileri ile ilgili tüm güncellemeleri ayrıştırma ve temizlemenin perspektifinden oldukça problemlidir. Bu yüzden uymak istediğim en iyi uygulamayı belirlemeye çalışıyorum.

Tamamen veri saklama ve analiz bakış açısıyla konuşan geographyPostGIS tipi antimeridyen düşünülerek tasarlandı (birkaç tasarım hedefi arasında). Tip için özel olarak tasarlanmış çeşitli fonksiyonlargeography vardır .

Örneğin, Taveuni, Fiji'de ( Büyük Çember Eşleştiricisi ile eşlenmiş) karşısındaki bir LineString'i düşünün:

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

Bu jeodezinin uzunluğu yaklaşık 46 km'dir. Benzer şekilde, ST_Area, +179 ile -179 arasında atlayan boylam koordinatlarında bile adanın Çokgeninde doğru çalışır.

Bir EPSG: 4326'nın geometrybir geographytüre dökülmesi de koordinatları normalleştirir, örneğin son koordinatın boylamı> 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]]}

geographyilk örnekte tam olarak aynı türe geri dönüştürülür , ancak şimdi GeoJSON çıkışı ile. BİLDİRİMİ (veya örn. SET client_min_messages TO WARNING;) Görmezden gelmeyi ve her türlü komik görünümlü geometriyi tür olarak dönüştürmeyi seçebilirsiniz geography.

Gösterilen geographyPostGIS dışında haritalarda türlerini farklı bir hikaye olduğunu ve umarım daha iyi cevaplar bu yönüyle değineceğim.

Elbette, tercih edilen cevap (1) 'dir, yani müşterilerin "doğru olanı" yapmasını isteyin. Dikkate alınması gereken iyi bir örnek, bu kml dosyasıyla yaklaştırılan Antarktika kıtasını temsil eden çokgendir.

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

Delta boylamsal kopmanın gerçekleştiği yerde kodlama veya kaydırma bu gibi verilere yardımcı olmaz. Antarktika'ya özgü bir projeksiyon çalışması işe yarayacaktır, ancak bu genel bir çözüm değildir.

Şaşırtıcı bir şekilde, Google Earth Pro bu çokgeni doğru göstermiyor ("anahat" modunu kullanmıyorsanız). Buraya bak