Articolo a cura di Chris Holmes, Visiting Fellow dell'OGC –
Nel mio precedente post ho delineato la visione per Cloud-Native Geospatial , ma con questo post voglio entrare nel dettaglio di ciò che è necessario. Descriverò le aree chiave in cui sono necessari standard fondamentali e poi esaminerò lo stato attuale di ciascuna area. Si va da aree piuttosto consolidate a aree piuttosto speculative, ma tutte sono eminentemente realizzabili. Infine, approfondirò l'area su cui mi sono concentrato maggiormente in questi ultimi mesi come Visiting Fellow dell'OGC.
Componenti necessari
Ci sono alcuni componenti chiave necessari per rappresentare diverse informazioni sulla posizione sul cloud. Questi si trovano "sotto" un'API: sono semplicemente risorse e formati. Insieme, questi componenti forniscono una solida base per rappresentare la maggior parte delle informazioni geospaziali sul cloud. Dovrebbero essere compatibili con le API; possono servire come risposte alle richieste, come risorse JSON o formati di streaming. Ma dovrebbe anche essere completamente possibile archiviarli semplicemente su un archivio di oggetti di archiviazione cloud (S3, GCP, ecc.). Questi a loro volta saranno spesso letti da API più capaci per eseguire operazioni interessanti, ma non è necessario.
Il nucleo che vedo è:
- Formato raster principale: Un formato cloud-native affidabile per gestire immagini satellitari, DEM, prodotti dati derivati principalmente da immagini satellitari, ecc.
- Formato raster multidimensionale: Un formato cloud in grado di gestire enormi cubi di dati, come i risultati delle previsioni meteorologiche, la temperatura nel tempo e l'altitudine, la modellazione climatica, ecc. Questo è lo spazio tradizionale di NetCDF / HDF.
- Formati vettoriali principali: L'ideale sarebbe un dato vettoriale equivalente al Cloud Optimized GeoTIFF, ma i diversi requisiti di visualizzazione rapida e analisi approfondita al volo potrebbero non essere facilmente combinabili, quindi potremmo ritrovarci con più di un formato.
- Formato della nuvola di punti: Un formato cloud che funziona come COG, ma consente la visualizzazione in streaming e l'analisi al volo dei cloud di punti.
- Metadati della raccolta e del set di dati: Titolo, descrizione, licenza, limiti spaziali e temporali, parole chiave, ecc. che consentono la ricerca. Per la baseline geospaziale nativa del cloud, questo dovrebbe concentrarsi sull'essere "scansionabile" e collegarsi a formati effettivi. Dovrebbe supportare diversi tipi di dati (dati vettoriali, dati raster, nuvole di punti, cubi di dati multidimensionali, video geolocalizzati, rappresentazioni 3D, ecc.) e dovrebbe essere sufficientemente flessibile da funzionare con qualsiasi dato. Dovrebbe essere fondamentalmente incentrato sulla geospazialità e non cercare di descrivere genericamente alcun dato.
- Metadati a livello di granulo/scena/risorsa: Un oggetto metadati flessibile con campi comuni per descrivere particolari domini di acquisizione dati e collegarsi ai file di dati effettivi.
La maggior parte di queste ha almeno un inizio di risposta nella nostra comunità geospaziale mondiale, se non una soluzione solida:
- Formato raster principale: Oggi questo è GeoTIFF ottimizzato per il cloud (COG). Sta per diventare uno standard ufficiale OGC e ha già visto un'adozione incredibile in un'ampia varietà di luoghi. È davvero il formato geo cloud-native fondamentale che ha dimostrato cosa è possibile. Vale la pena notare che potrebbe non essere la soluzione definitiva per i formati raster cloud, poiché si potrebbe vedere un formato immagine più ottimizzato, più piccolo e veloce. Ma probabilmente sarebbe un formato immagine più generale a cui la nostra comunità aggiunge "geo" come abbiamo fatto con TIFF. I COG domineranno per un po', poiché la retrocompatibilità con gli strumenti legacy è difficile da battere mentre siamo ancora all'inizio della transizione verso l'infrastruttura geospaziale cloud-first.
- Formato raster multidimensionale: C'è già un'ottima risposta qui con zarroÈ in corso il processo di adottato come standard comunitario OGC, con il voto di adozione che inizierà presto. È anche in corso abbracciato da NetCDFe ha riscontrato un notevole entusiasmo da parte della comunità impegnata nella salvaguardia del clima.
- Formati vettoriali principali: Non c'è ancora una grande risposta qui. Discuterò il panorama e le varie possibilità in un futuro post del blog.
- Formato della nuvola di punti: Il nuovo film di Howard Butler Formato COPC è una "specifica LASzip organizzata, compressa e leggibile in intervalli" che rispecchia tutti gli standard del GeoTIFF ottimizzato per il cloud e che probabilmente verrà adottata rapidamente.
- Metadati della raccolta e del set di dati: ha un nucleo solido con la costruzione OGC API – Features 'Collection'. Il Collezione STAC quindi estende questo, e l'API OGC – Record fornisce un equivalente GeoJSON che può essere utilizzato come ritorno nelle query di ricerca. Ma queste parti non sono state tutte collegate in modo coerente, e l'uso completo "statico" (solo caricamento su S3) non è stato completamente sviluppato. Questo è stato il focus principale del mio lavoro negli ultimi mesi, quindi mi immergerò più a fondo di seguito.
- Metadati a livello di granulo/scena/risorsa: è dove il Catalogo delle risorse spaziotemporali (STAC) La specifica su cui mi sono concentrato principalmente negli ultimi anni ha avuto successo e sta riscuotendo un'ottima adozione dopo aver recentemente raggiunto la versione 1.0.0.
E le piastrelle?
Per quanto mi riguarda, non ho ancora deciso se una specifica per le tessere web sia davvero adatta a un vero standard geospaziale cloud-native. Credo che per le tessere raster (png, jpeg, ecc.) non abbia senso, dato che un GeoTIFF ottimizzato per il cloud può essere facilmente trasformato al volo in tessere web, utilizzando strumenti serverless come Titiler . Pertanto, la strategia migliore è utilizzare un buon formato cloud-native che consenta il rendering e l'elaborazione al volo nel formato richiesto dai client. Le tessere sono essenziali per i client basati su browser, ma altri strumenti traggono maggior beneficio dall'accesso diretto ai dati. Una volta finalizzato lo standard OGC API – Tiles, probabilmente avrà senso creare un "elemento costitutivo per i metadati delle tessere" che possa fungere da formato cloud-native per indirizzare i client verso le tessere.
Per quanto riguarda le tile vettoriali, considererei sia i formati MVT che PBF come formati geospaziali cloud-native, in quanto possono risiedere su un bucket di archiviazione cloud ed essere utilizzati da diverse applicazioni. Credo però che ci sia del potenziale per un buon formato vettoriale cloud-native che funzioni come i COG, con un server di tile serverless in grado di renderizzare le tile vettoriali al volo. Approfondirò questa idea in un futuro articolo sui formati vettoriali.
Come si inseriscono le API OGC?
L' iniziativa OGC API rappresenta una rivisitazione del modello OGC W*S, trasformandolo in API JSON/REST più moderne. In generale, si colloca un livello "sopra" le strutture geospaziali native del cloud qui discusse, definendo interfacce API per servizi che utilizzano i formati nativi del cloud (ma che potrebbero anche utilizzare formati più tradizionali e database spaziali). Queste API offrono molte più funzionalità, come la ricerca dinamica o l'elaborazione dei dati in tempo reale, ma richiedono anche maggiori risorse. La maggior parte delle strutture di metadati native del cloud sono state estratte dalle API, pertanto le varianti native del cloud dovrebbero essere compatibili con le API OGC, pur essendo meno complete (ma anche molto più facili da implementare).
Un ecosistema ideale vedrebbe la maggior parte dei dati archiviati in formati geospaziali cloud-native, e poi un'ampia gamma di servizi su di essi, con la maggior parte di essi che implementa interfacce API OGC. In futuro, si spera che sarà banale installare un server o anche una funzione serverless che fornisca query API OGC più ricche sui metadati e formati cloud-native.
Verso metadati di raccolta geospaziale cloud-native
Come accennato in precedenza, la maggior parte del mio tempo da Visiting Fellow dell'OGC negli ultimi mesi è stata dedicata alla sistemazione di una "raccolta geospaziale cloud-native". Ci sono alcuni aspetti diversi in questo.
Una collezione OGC statica
Uno dei costrutti più potenti emersi nell'evoluzione di STAC è lo "STAC statico". Per un'ottima sintesi di cosa siano e come funzionino, si veda il post "Static Spatiotemporal Asset Catalogs in Depth". Per citare le " migliori pratiche " della versione 1.0.0 della specifica:
Un catalogo statico è un'implementazione della specifica STAC che non risponde dinamicamente alle richieste. Si tratta semplicemente di un insieme di file su un server web collegati tra loro in modo da poter essere indicizzati, spesso archiviati in un servizio di cloud storage come Amazon S3 , Azure Storage e Google Cloud Storage . Un catalogo statico può essere indicizzato solo dai motori di ricerca e dai cataloghi attivi; non può rispondere alle query. Tuttavia, è incredibilmente affidabile, poiché non ci sono componenti in movimento, cluster o database da gestire.
Si è rivelato un metodo molto diffuso per pubblicare dati STAC, realizzando la visione espressa nel mio precedente post sul blog di poter caricare i dati sul cloud e farli "semplicemente funzionare".
Ma mentre STAC ha introdotto opzioni statiche chiare sia per singoli elementi di immagini e altri asset spazio-temporali, sia per collezioni di questo tipo di dati, mancava un equivalente "collezione statica" per i dati vettoriali. L'API OGC – Feature Collection (che STAC estende per la sua Collection ), come specificato, è solo una parte di una risposta API, non una risorsa JSON indipendente utilizzabile autonomamente. Tuttavia, si trattava di una parte modulare ben progettata e Clemens Portele e Peter Vretanos, i redattori della specifica Features, hanno sempre sostenuto la sua estrazione.
ho fatto un tentativo approssimativo in un repository github sperimentale. Ma poi Clemens ha tirato fuori un'altra idea che avevamo in mente di creare veri piccoli blocchi granulari di costruzione dalla baseline dell'API OGC (cercherò di scrivere un post completo su questo in futuro). Ciò ha portato a un 'Collezione', estratto da OGC API – Features, ma scritto come una risorsa JSON indipendente che potrebbe essere riutilizzata in qualsiasi contesto. E quindi abbiamo una vera e propria "raccolta OGC statica", in grado di vivere staticamente sullo storage cloud. Questo può indicare un GeoJSON, GeoPackage, Shapefile o qualsiasi nuovo formato più cloud-native. Puoi vedere un esempio di questo in un repository che ho creato per sperimentare esempi di collezioni statiche. Quello ha più rappresentazioni degli stessi dati in formati diversi, ma potrebbe facilmente averne solo uno.
Allineamento record + STAC
Un'altra parte considerevole del mio tempo è stata dedicata a un lavoro che non è direttamente legato al cloud-native: l'allineamento completo di STAC con l'API OGC – Records . Molti non erano sicuri dell'esatta relazione tra le due specifiche, sebbene io avessi sempre avuto idee chiare (ma non ben comunicate). Quindi, gli ultimi mesi mi hanno permesso di sincronizzarmi completamente con il team principale di Records e di raggiungere un accordo sulla strada da seguire. In breve, l'API Records ha un ruolo fondamentale in STAC, poiché abbiamo rimandato la " ricerca a livello di collezione " perché volevamo allinearla completamente con Records. Ma l'aspetto che crea confusione è che un'API Records può essere utilizzata anche per cercare elementi simili a STAC ed è effettivamente progettata per la ricerca di quasi qualsiasi cosa.
Il momento decisivo è stato capire che gli autori della specifica Records avevano sempre in mente un "Data Record", che è esattamente ciò di cui STAC ha bisogno, ovvero qualcosa di più specifico rispetto a un Record generico e flessibile. La struttura Collection di STAC si concentra principalmente su ciò che OGC considera "dataset", ma non c'è stata una specifica chiara di tale struttura nella baseline API di OGC in fase di sviluppo. Ho avviato una pull request nel repository Records per aggiungerla e proporrò anche una "Data Collection" che estende la Collection OGC di base con campi aggiuntivi. Una STAC Collection, a sua volta, dovrebbe idealmente essere in linea con la struttura Dataset Collection. In futuro, collaboreremo per creare un "STAC Record" che allinei completamente un STAC Item ai requisiti più generali dei record.
Un altro effetto positivo di questa sincronizzazione è stata la notevole riorganizzazione della specifica principale dell'API Records da parte di Peter Vretanos. L'idea è sempre stata che l'API Records fosse un'API Features, ma con alcune funzionalità aggiuntive (ad esempio, ordinamento e query più ricche) e un modello dati più controllato. La nuova versione chiarisce molto meglio questo concetto, evidenziando le parti che si differenziano dalle API OGC principali, e dovrebbe essere molto più facile allinearla con STAC.
Record statici
Tutto questo lavoro ha gettato le basi per il prossimo componente geospaziale nativo del cloud: un catalogo indicizzabile composto da record statici accessibili via web! Peter ha pubblicato un esempio di catalogo indicizzabile (e io ho una pull request che espande l'esempio con una "collezione OGC statica" con dati vettoriali), che necessita di qualche ritocco per essere allineato con STAC, ma si adatta a tutti i nostri principi geospaziali nativi del cloud. Quindi ora abbiamo praticamente tutti gli elementi necessari per i metadati corretti di cui abbiamo bisogno per una base di riferimento geospaziale nativa del cloud. Record e collezioni sono fondamentalmente due istanze alternative degli stessi modelli di dati principali: una è GeoJSON, il che semplifica la visualizzazione di molti record insieme, e l'altra corrisponde alla struttura principale dell'API OGC Collection, ampiamente utilizzata. Nel breve termine, la best practice sarà probabilmente quella di utilizzarli entrambi, ma col tempo probabilmente ci saranno strumenti che consentiranno una facile conversione dall'uno all'altro, soprattutto se riusciremo a rendere i modelli di dati principali completamente compatibili.
Mettere tutto insieme
Quindi siamo allettantemente vicini alla suite completa di metadati statici necessari per gestire la maggior parte dei dati geospaziali cloud-native. Il compito principale da svolgere è allineare completamente il lavoro in OGC API – Records e – Features per essere compatibile con STAC e descrivere meglio tutti i campi di metadati necessari. Ci sono alcuni modi in cui le cose sono un po' diverse in questo momento, quindi sarebbe bello semplificare un po' le cose tra i due approcci.
Per mostrare come tutto possa funzionare insieme, ho creato un repository di " esempi ogc statici " per dimostrare come sia possibile avere a disposizione diversi set di dati e formati da una struttura completamente statica. Continuerò ad ampliarlo e a sviluppare gli esempi, e a rendere più dettagliati i file README per illustrare il funzionamento. In futuro, cercherò di scrivere un post sul blog che approfondisca l'argomento.
I post futuri approfondiranno di più lo stato degli attuali formati geospaziali cloud-native. Ultimamente ho dedicato la maggior parte del mio tempo ai dati vettoriali, poiché non esiste una risposta molto chiara. Spero anche di dedicare più tempo a evidenziare zarr e copc, poiché sono due grandi sforzi che si adattano bene e completano davvero un ecosistema completo di formati.
