Jaka jest najlepsza praktyka do przechowywania obiektów geograficznych (linii, wielokątów i ich wieloczęściowych odpowiedników), gdy obejmują one antimeridian (długość geograficzna ± 180 °) i muszą być wysyłane do aplikacji klienckich i otrzymywane z nich jako GeoJSON?
Zaczynam pracę od interfejsu API po stronie serwera z obsługą bazy danych Postgres / PostGIS do pracy z historycznymi i prognozowanymi ścieżkami cyklonów tropikalnych i promieniami wiatru. Wiele cyklonów na Oceanie Spokojnym ma niefortunną tendencję do przekraczania antymerydyny, czasami wielokrotnie w ciągu ich życia:
Jako Nowozelandczyk żyjący w pobliżu antymerydyjczyków często napotykałem ten problem w danych regionalnych, aby opracować pewne strategie radzenia sobie, ale chciałbym dowiedzieć się, co jest uważane za najlepszą praktykę. Niestety nie ma istniejących pytań oznaczonych jako antimeridian , więc trudno jest znaleźć podobne pytania. Wszystkie te pytania, które widziałem, borykając się z tym problemem, wydają się szukać porady specyficznej dla aplikacji. To pytanie krótko omawia antimeridian w przypadku obejmującego całą ziemię wielokąta GeoJSON bez granic. To pytanie jest bardzo zbliżone do tego, o co pytam.
Muszę przechowywać historyczne i prognozowane cyklony w przestrzennej bazie danych, ale przewiduję, że wystąpią problemy z antymerydianem. Na przykład linia rozpoczynająca się na szerokości / długości geograficznej (0,179)i kończąca się na (0,-179)jest niejednoznaczna w odniesieniu do swojego kierunku: czy kroczy krótką ścieżką przez antymerydyzm, czy „owija się” wokół całej planety. Jak taka ścieżka powinna być przechowywana w przestrzennej bazie danych (konkretnie pracuję z PostGIS, ale mam nadzieję, że rozwiązanie jest wystarczająco ogólne)? Niektóre pomysły, które mam:
- Nie zmieniaj geometrii elementów i niejednoznaczność przenieś do aplikacji klienckich.
- Podziel dowolną cechę przecinającą antimeridian na wieloczęściową geometrię z przerwą na antimeridian . ( Specyfikacja GeoJSON obsługuje nazwane CRS .)
- Pracuj z nieglobalnymi projekcjami dla różnych basenów cyklonowych lub regionów oceanicznych, które nie mają takiej nieciągłości
- Wykorzystując fakt, że cyklon nigdy nie zaobserwował podróżowania po całej planecie, przechowuj współrzędne cyklonów rozpoczynające się w zakresie szerokości geograficznej
(90,-90)przesuniętym o fazę 360 ° (utrzymując pozostałe -180–180 °) - Wykorzystując fakt, że cyklon jest bardzo mało prawdopodobny na południe od południowego krańca Afryki, skorzystaj z przerwy na 30 ° długości geograficznej (jak na powyższej mapie).
- Pozwól współrzędnym wykraczać poza prawidłowy zakres EPSG 4326 , np.> 180 ° i <-180 ° dla wszystkich elementów przechodzących przez antimeridian.
- Kodowanie Delta , jak w TopoJSON (np. Początek o,
(0,-179)a następnie następna współrzędna to-3szerokość geograficzna zachodnia). Nie mam pojęcia, czy i jak to zaimplementować podczas przechowywania danych w PostGIS, ale jest to świetne rozwiązanie do wysyłania danych do aplikacji klienckich. - Jakaś forma notacji wektorowej lub współrzędnych biegunowych. (Wydaje się raczej trudne i niezwykłe.)
Spośród nich nie lubię pomysłów 2–5, ponieważ nie są one ogólne, ale lubię je, ponieważ mają sens dla mojej konkretnej aplikacji. W przypadku aplikacji zajmujących się tylko danymi na Oceanie Spokojnym mogą one mieć sens, więc nie chcę ich całkowicie pomijać jako opcji.
Pomysły 6 i 7 zostały zaczerpnięte z bloga Toma MacWrighta , który jest wart przeczytania, ale nie jest rozstrzygający w odniesieniu do antimeridian.
Idea 4 jest używana przez GeographicaGSGeodesicLinesToGISPython , która z kolei stosuje fiona.transform.transform_geomz przesunięciem antimeridian 360 °. Z kolei Fiona używa OGR -wrapdateline. Przypuszczam, że to bardzo solidny precedens i właściwie raczej ogólny.
W związku z kwestią przechowywania muszę rozważyć, w jaki sposób takie funkcje powinny być wysyłane do aplikacji klienckich oraz w jaki sposób moja aplikacja powinna rozpatrywać dane przesłane z powrotem do niej (np. Ludzki prezenter zmieniający prognozowaną ścieżkę cyklonu na Pacyfiku). Format wymiany prawdopodobnie będzie GeoJSON, ale nie musi tak być.
Niestety specyfikacja GeoJSON nie zawiera wyraźnych informacji na temat zagadnień antymerydyńskich. To z Wikipedii :
Wiele bibliotek oprogramowania geograficznego lub formatów danych rzutuje świat na prostokąt; bardzo często ten prostokąt jest dzielony dokładnie na 180. południku. To często uniemożliwia wykonywanie prostych zadań (takich jak reprezentowanie obszaru lub linii) na 180. południku. Kilka przykładów:
Specyfikacja GeoJSON nie wspomina o obsłudze 180. południka w swojej specyfikacji, dlatego reprezentacje linii przecinających 180. południk można równie dobrze zinterpretować jako przebiegające dookoła świata.
W OpenStreetMap obszary (takie jak granica Rosji) są podzielone na południku 180.
Moje czytanie jest takie, że GeoJSON nie ma szczególnego standardowego przedstawienia cech obejmujących antymerydyny i jest celowo pozostawiony niejednoznaczny (geometria wieloczęściowa rozwiązałaby prawdopodobnie problem). Podobnie w OpenStreetMap istnieją podziały geometryczne na antimeridian, chociaż nie wiem, czy takie podzielone cechy są wieloczęściowe, czy w rzeczywistości dyskretne.
Jest to dość problematyczne, szczególnie z punktu widzenia tworzenia obwiedni lub innych żądań przestrzennych obejmujących tę linię, ale także podczas analizowania i odkażania danych wejściowych oraz wszelkich aktualizacji geometrii elementów. Właśnie dlatego staram się ustalić najlepszą praktykę, do której mogę dążyć.
