Передовий досвід для баз даних та API з географічними даними, що охоплюють антимеридіан

Яка найкраща практика зберігання географічних особливостей (ліній, багатокутників та їхніх багаточастинкових еквівалентів), коли ці особливості охоплюють антимерідіані (довжина ± 180 °), і їх потрібно надсилати та отримувати з клієнтських веб-додатків як GeoJSON?

Я починаю роботу над серверним веб-API з підтримкою бази даних Postgres / PostGIS, щоб працювати з історичними та прогнозними траєкторіями тропічного циклона та радіусами вітру. Багато циклонів у Тихому океані мають невдалу схильність до перетину антимеридіану, іноді багаторазово протягом свого життя:

Як новозеландець, що мешкає поблизу антимеридіану, я стикався з цією проблемою досить часто в регіональних даних, щоб мати деякі стратегії подолання, але хотів би насправді з’ясувати, що вважається найкращою практикою. На жаль, не існує жодних питань, позначених антимерідіаном , тому важко знайти відповідні запитання. З усіх питань, які я бачив, як боролася з цією проблемою, начебто шукають дуже конкретної поради. У цьому питанні коротко обговорюється антимеридіан для випадку земляного полігону GeoJSON без меж. Це питання досить близьке до того, що я задаю.

Мені потрібно зберігати історичні та прогнозні циклони в просторовій базі даних, але я припускаю, що з антимеридіаном виникнуть проблеми. Наприклад, лінія, що починається на широті / довготі (0,179)і закінчується на (0,-179), неоднозначна щодо її напрямку: чи йде вона коротким шляхом по антимерідіану, або "обмотає" всю планету. Як такий шлях повинен зберігатися в просторовій базі даних (конкретно я працюю з PostGIS, але сподіваюся, що рішення є загальним)? Деякі ідеї, які у мене є:

1. Не змінюйте геометричні характеристики та перекладайте неоднозначність на клієнтські програми.
2. Розділіть будь-яку особливість, що перетинає антимеридіан на багаточастотну геометрію з розривом на антимеридіан . ( Специфікація GeoJSON підтримує названі CRS .)
3. Робота з неглобальними прогнозами для різних циклонових басейнів або океанічних регіонів, які не мають такого розриву
4. Використовуючи той факт, що циклон ніколи не спостерігав, щоб подорожувати по всій планеті, зберігайте координати циклонів, починаючи з діапазону широти, зміщеного (90,-90) фазою 360 ° (зберігаючи інші -180-180 °)
5. Користуючись тим, що циклон вкрай малоймовірний на південь від південного краю Африки, використовуйте перерву на 30 ° довготи (як на наведеній вище карті).
6. Дозвольте координатам виходити за межі допустимого діапазону EPSG 4326 , наприклад> 180 ° та <-180 ° для будь-яких особливостей, що передають антимеридіан.
7. Кодування дельти , як у TopoJSON (наприклад, початок на, (0,-179)а далі наступна координата - -3широта на захід). Я не маю уявлення, чи потрібно це реалізувати під час зберігання даних у PostGIS, але це чудове рішення для надсилання даних клієнтським програмам.
8. Певна форма позначення вектора або полярні координати. (Здається, досить складно і незвично.)

З них мені не подобаються ідеї 2–5, оскільки вони не є загальними, але мені подобаються, тому що вони мають певний сенс для мого конкретного застосування. Для додатків, що займаються лише даними в Тихому океані, вони можуть мати багато сенсу, тому я не хочу повністю знижувати їх як варіанти.

Ідеї ​​6 та 7 були викладені з блогу Тома МакРайта , який варто прочитати, але не є переконливим щодо антимеридіану.

Ідея 4 використовується GeographicaGS 'GeodesicLinesToGISPython , який, у свою чергу, використовує fiona.transform.transform_geomантимедіанічне зміщення на 360 °. У свою чергу, Fiona використовує OGR -wrapdateline. Я думаю, це дуже солідний прецедент і насправді досить загальний.

У поєднанні з проблемою зберігання даних мені потрібно розглянути, як такі функції слід надсилати клієнтським програмам, і як моя програма повинна враховувати дані, що надсилаються до неї (наприклад, людський синоптик, що змінює прогнозну доріжку циклону в Тихому океані). Формат обміну, ймовірно, буде GeoJSON, але не повинен бути.

На жаль, специфікація GeoJSON не є явною щодо антимеридіанських проблем. Це з Вікіпедії :

Багато бібліотек або формат даних географічного програмного забезпечення проектують світ на прямокутник; дуже часто цей прямокутник розбивається рівно на 180-му меридіані. Це часто унеможливлює виконання простих завдань (наприклад, зображення області чи лінії) над 180-м меридіаном. Деякі приклади:

• Специфікація GeoJSON не згадує обробку 180-го меридіана в його специфікації, як таке, зображення ліній, що перетинають 180-й меридіан, так само може бути інтерпретоване як проходження по всьому світу.

• У OpenStreetMap ділянки (як і межа Росії) розділені на 180-му меридіані.

Я читаю, що GeoJSON не має особливого стандартного представлення особливостей, що охоплюють антимеридіани, і це навмисно залишається неоднозначним (багаточастинні геометрії, можливо, вирішать цю проблему). Аналогічно у OpenStreetMap є антиметрійні підрозділи геометрії, хоча я не знаю, чи є такі розділені функції багаточастинні або насправді дискретні записи.

Це здається досить проблематичним, особливо з точки зору внесення обмежувальної рамки чи інших просторових запитів, що охоплюють цю лінію, але також при аналізі та санітарії введення та будь-яких оновленнях для геометрії. Ось чому я намагаюся визначити найкращу практику, яку я можу прагнути дотримуватися.

Якщо говорити виключно з точки зору зберігання та аналізу даних, geographyтип для PostGIS був розроблений з урахуванням антимеридіану (серед кількох цілей дизайну). Існує кілька функцій, спеціально розроблених для цього geographyтипу .

Наприклад, розглянемо LineString через Тавеуні, Фіджі ( картографується Великим колом Mapper ), який обшиває антимеридіан :

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

Довжина цієї геодезичної форми - близько 46 км. Так само ST_Area працював би правильно на полігоні острова, навіть якщо координати довготи стрибали між +179 та -179.

Закидання EPSG: 4326 geometryдо geographyтипу також нормалізує координати, наприклад, довгота останньої координати становить> 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]]}

перетворюється назад в точно такий же geographyтип у першому прикладі, але тепер з виходом GeoJSON. Ви можете ігнорувати ПОВІДОМЛЕННЯ (або наприклад SET client_min_messages TO WARNING;) та конвертувати всі види смішних геометрій у geographyтипи.

Відображення geographyтипів на картах поза PostGIS - це вже інша історія, і, сподіваємось, кращі відповіді стосуватимуться цього аспекту.

Безумовно, кращою відповіддю є (1), тобто, якщо клієнти роблять «правильну справу». Хороший випадок, який слід врахувати, - це полігон, що представляє континент Антарктида, який наближається до цього файлу kml

<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, де відбувається розрив довготи, не допоможе таким даних. Опрацювати його може спрацьовування, характерне для Антарктиди, але це навряд чи загальне рішення.

Дивно, але Google Планета Земля Pro не показує цей полігон правильно (якщо ви не використовуєте режим "контур"). Дивіться тут