Qual è la best practice per la memorizzazione di funzioni geografiche (linee, poligoni e loro equivalenti multipart) quando queste funzionalità si estendono sull'antimeridiano (± 180 ° di longitudine) e devono essere inviate e ricevute dalle applicazioni Web client come GeoJSON?
Sto iniziando a lavorare su un'API Web lato server con il supporto di un database Postgres / PostGIS per lavorare con piste ciclabili tropicali e previsioni e raggi del vento tropicali. Molti cicloni nell'Oceano Pacifico hanno la sfortunata tendenza ad attraversare l'antimeridiano, a volte più volte nella loro vita:
Come neozelandese che vive vicino all'antimeridiano, ho riscontrato questo problema abbastanza spesso nei dati regionali per avere alcune strategie di coping, ma vorrei davvero scoprire quale sia considerata la migliore pratica. Sfortunatamente non ci sono domande taggate antimeridian , quindi è difficile cercare domande correlate. Quelle domande che ho visto lottare contro questo problema sembrano tutte cercare consigli molto specifici per l'applicazione. Questa domanda discute brevemente l'antimeridiano per il caso di un poligono GeoJSON che si estende sulla terra senza confini. Questa domanda è abbastanza vicina a quello che sto chiedendo.
Devo memorizzare i cicloni storici e di previsione in un database spaziale, ma prevedo che ci saranno problemi con l'antimeridiano. Ad esempio, una linea che inizia a latitudine / longitudine (0,179)e termina a (0,-179)è ambigua rispetto alla sua direzione: se prende il breve sentiero attraverso l'antimeridiano o "avvolge" l'intero pianeta. Come dovrebbe essere memorizzato un tale percorso in un database spaziale (in particolare sto lavorando con PostGIS ma spero che la soluzione sia abbastanza generica)? Alcune idee che ho:
- Non apportare modifiche alle geometrie delle caratteristiche e sposta l'ambiguità sulle applicazioni client.
- Dividi qualsiasi caratteristica che attraversa l'antimeridiano in una geometria multipart con una rottura nell'antimeridiano . ( La specifica GeoJSON supporta CRS denominati .)
- Lavora con proiezioni non globali per diversi bacini di cicloni o regioni oceaniche che non hanno una tale discontinuità
- Sfruttando il fatto che non è mai stato osservato che un ciclone viaggi in tutto il pianeta, memorizza le coordinate dei cicloni che iniziano nella gamma di latitudine
(90,-90)sfalsate di una fase di 360 ° (mantenendo gli altri -180-180 °) - Sfruttando il fatto che un ciclone è estremamente improbabile a sud della punta meridionale dell'Africa, usa una pausa a 30 ° di longitudine (come nella mappa sopra).
- Consentire alle coordinate di estendersi oltre l'intervallo valido di EPSG 4326 , ad es.> 180 ° e <-180 ° per tutte le funzioni che superano l'antimeridiano.
- Codifica delta , come in TopoJSON (ad es. Iniziare da
(0,-179)e quindi la coordinata successiva è-3latitudine ovest). Non ho idea se o come implementarlo durante la memorizzazione dei dati in PostGIS, ma questa è un'ottima soluzione per l'invio di dati alle applicazioni client. - Qualche forma di notazione vettoriale o coordinate polari. (Sembra piuttosto difficile e insolito.)
Di questi, non mi piacciono le idee 2–5 perché non sono generiche, ma mi piacciono perché hanno un senso per la mia particolare applicazione. Per le applicazioni che si occupano solo di dati nell'Oceano Pacifico, potrebbero avere molto senso, quindi non voglio scartarli completamente come opzioni.
Le idee 6 e 7 sono state sollevate dal blog di Tom MacWright , che vale la pena leggere ma non è conclusivo rispetto all'antimeridiano.
Idea 4 è utilizzato da GeographicaGS 'GeodesicLinesToGISPython , che a sua volta utilizza fiona.transform.transform_geomun offset antimeridico a 360 °. A sua volta, Fiona sta usando OGR -wrapdateline. Suppongo che sia un precedente molto solido e in realtà piuttosto generico.
In concomitanza con il problema dell'archiviazione, devo considerare come inviare tali funzionalità alle applicazioni client e in che modo la mia applicazione dovrebbe prendere in considerazione i dati inviati ad esso (ad esempio un meteorologo umano che modifica la traccia di previsione di un ciclone nel Pacifico). Il formato di interscambio sarà probabilmente GeoJSON, ma non è necessario.
Sfortunatamente la specifica GeoJSON non è esplicita sui problemi degli antimeridiani. Questo da Wikipedia :
Molte librerie di software geografici o formati di dati proiettano il mondo su un rettangolo; molto spesso questo rettangolo viene diviso esattamente al 180 ° meridiano. Ciò rende spesso impossibile svolgere semplici compiti (come rappresentare un'area o una linea) oltre il 180 ° meridiano. Qualche esempio:
La specifica GeoJSON non menziona la gestione del 180 ° meridiano nella sua specifica, in quanto tale, le rappresentazioni di linee che attraversano il 180 ° meridiano possono essere interpretate come girando il mondo.
In OpenStreetMap, aree (come il confine con la Russia) sono divise al 180 ° meridiano.
La mia lettura è che GeoJSON non ha una particolare rappresentazione standard delle funzionalità di antimeridian-spanning ed è volutamente lasciato ambiguo (le geometrie multi-parte risolverebbero forse il problema). Allo stesso modo in OpenStreetMap ci sono divisioni geometriche nell'antimeridiano, anche se non so se tali funzioni divise siano multipart o in realtà record discreti.
Ciò sembra piuttosto problematico, soprattutto dal punto di vista del bounding box o di altre richieste spaziali che si estendono su questa linea, ma anche nell'analisi e nella sanificazione dell'input e di eventuali aggiornamenti delle geometrie delle caratteristiche. Questo è il motivo per cui sto cercando di determinare una best practice a cui posso cercare di conformarmi.
