I cubi di dati geospaziali sono usati frequentemente oggigiorno per consentire l'accesso e l'analisi di dati geospaziali performanti e compatibili con il cloud. Tuttavia, le differenze nella loro progettazione, nelle interfacce e nella gestione delle caratteristiche temporali stanno causando sfide di interoperabilità per chiunque interagisca con più di una soluzione. Tali sfide sprecano inutilmente tempo e denaro e, da una prospettiva scientifica, influiscono sulla riproducibilità.
Per affrontare queste sfide, l'Open Geospatial Consortium (OGC) e il Group on Earth Observation (GEO) hanno invitato esperti globali di data cube a discutere lo "stato dell'arte" e a trovare una soluzione al workshop "Towards Data Cube Interoperability" . Il workshop di due giorni, svoltosi alla fine di aprile 2021, è iniziato con una serie di dichiarazioni di posizione preregistrate da parte di fornitori e utenti di data cube. Questi video sono serviti come punto di partenza per intense discussioni che non solo hanno prodotto una nuova definizione del termine "data cube", ma hanno anche sottolineato la necessità di un approccio basato su API "incentrato sull'utente" che esponga non solo i dati a disposizione dell'utente, ma anche gli algoritmi di elaborazione che possono essere eseguiti su di essi, consentendo all'utente di aggiungerne di propri. I risultati del workshop sono stati pubblicati sulla pagina web del workshop "OGC & GEO Towards Data Cube Interoperability".
Cubi di dati dal punto di vista degli utenti
Le definizioni esistenti di cubi di dati si concentrano spesso sull'aspetto della struttura dei dati, così come viene utilizzato nell'informatica. Al contrario, il workshop "Towards Data Cube Interoperability" ha sottolineato la necessità di abbandonare queste definizioni e concentrarsi sulla prospettiva dell'utente. Agli utenti non interessa se i dati sono archiviati in un database relazionale, in un archivio di oggetti basato su cloud o in un file server. Ciò che interessa agli utenti è come possono accedere ai dati e agli algoritmi di elaborazione che possono applicarvi. Qualsiasi standard di accesso dovrebbe riflettere questo aspetto.
Ciò ha portato a un interessante ripensamento di cosa sia e cosa possa essere un cubo di dati. Sebbene non sia stato concordato su una base di consenso formale, i partecipanti al workshop hanno generalmente preso una definizione incentrata sull'utente di un cubo di dati geografici come:
"Un cubo di dati geografici è un modello discretizzato della Terra che offre i valori stimati di determinate variabili per ogni cella. Idealmente, un cubo di dati è denso (vale a dire, non include celle vuote) con distanza costante tra le celle per le sue dimensioni spaziali e temporali. Un cubo di dati descrive la sua struttura di base, vale a dire, le sue caratteristiche spaziali e temporali e le sue variabili supportate (alias proprietà), come metadati. È ulteriormente definito da un set di funzioni. Queste funzioni descrivono i metodi di scoperta, accesso, visualizzazione, analisi ed elaborazione disponibili tramite i quali l'utente può interagire con il cubo di dati."
Come possiamo vedere, il cubo di dati è descritto per l'utente, non per i dati. Non importa se il cubo di dati contiene una, due o tre dimensioni spaziali, o se al tempo vengono fornite le sue dimensioni o è solo parte dei metadati di un'osservazione, o non è affatto rilevante per i dati. Allo stesso modo, non importa come vengono archiviati i dati. Ciò che unificherà questi cubi di dati eterogenei è il loro utilizzo di un'API standardizzata basata su HTTP come metodo di accesso e interazione.
La preoccupazione principale dell'utente è quali funzioni offre l'istanza del cubo dati per applicarle ai dati. Queste funzioni sono ciò che differenzia principalmente la definizione del cubo dati incentrata sull'utente rispetto ad altre definizioni. Un utente deve capire quali domande possono essere poste per accedere ai dati che soddisfano specifici criteri di filtro, come visualizzare specifici (sotto-)set di dati o come eseguire funzioni analitiche e altri processi sul cubo dati. Se supportato, l'utente deve anche capire come aggiungere i propri processi al cubo dati in modo che possano essere eseguiti direttamente sul cubo dati senza la necessità di trasferire grandi quantità di dati dal cloud.
Ciò non significa che tutte le altre caratteristiche, come i dettagli spaziali e temporali (ad esempio, essere densi o sparsi, sovrapposti o perfettamente allineati, distanze costanti o incostanti) e i dettagli delle proprietà (scale di misurazione, dati incompleti, metodi di interpolazione, valori di errore, ecc.) non siano di interesse per l'utente: devono comunque essere noti. In quanto tali, saranno forniti tramite l'API del cubo di dati come metadati, in modo che l'utente possa tenerne conto quando valuta il modo migliore per elaborare i dati.
Interoperabilità tramite un'API Data Cube
Dove lascia questo OGC? Pensiamo che un approccio flessibile basato su API agli standard fornirà agli utenti finali, agli sviluppatori software e agli operatori di data cube la migliore esperienza.
Per gli utenti finali: un'unica API HTTP semplice e standardizzata, facile da imparare e/o programmare, indipendentemente da dove risiedano i dati, si tradurrà in una maggiore selezione di software disponibili (incluse piattaforme low-code o no-code), a supporto di una più ampia scelta di fornitori di data cube e di un maggior numero di algoritmi di elaborazione. Da una prospettiva scientifica, ciò significa che lo scienziato atmosferico non dovrà necessariamente essere anche un esperto di Python, potendo potenzialmente utilizzare l'interfaccia grafica di una piattaforma low-code o no-code per creare un algoritmo che elabori i dati per il suo studio sulle ondate di calore in Germania. Un altro scienziato atmosferico potrebbe poi utilizzare lo stesso algoritmo di elaborazione e applicarlo al Regno Unito con modifiche minime, anche se i dati necessari sono detenuti da un diverso fornitore di dati conforme agli standard. Questo approccio aumenta notevolmente la trasparenza e la ripetibilità degli studi scientifici e di altre preziose attività di analisi.
Per gli sviluppatori di software: un'unica API HTTP semplice e standardizzata significa che non devono progettare metodi specifici di ciascun fornitore per accedere ai data cube nel loro software. Possono invece interagire con i data cube tramite chiamate HTTP, beneficiando così di una semplice comunicazione Web standard, anziché di interazioni a livello di programmazione. Aderendo a uno standard concordato, gli sviluppatori possono lavorare con qualsiasi data cube conforme, riducendo al minimo gli adattamenti specifici per ciascun cubo. Ciò aumenta l'usabilità del software, diminuendo al contempo i costi di sviluppo e manutenzione.
Per gli operatori di data cube: l'utilizzo di un'unica API HTTP semplice e standardizzata riduce i costi di sviluppo e manutenzione, ampliando al contempo la base clienti. La conformità agli standard consente ai fornitori di raggiungere clienti che utilizzano qualsiasi pacchetto software compatibile, anziché solo quelli che utilizzano un elenco selezionato di software programmati per funzionare con la specifica istanza. Ciò significa che un maggior numero di persone programmerà per il vostro data cube, anche se non sono a conoscenza dell'esistenza del vostro servizio.
Quali sono i prossimi passi per l'OGC?
È ancora presto per dirlo, ma potete aspettarvi che un'API relativa ai cubi di dati entri a far parte della nostra famiglia di standard API OGC . Il lavoro su questa API per i cubi di dati si basa sul lavoro della nostra piattaforma di sfruttamento delle osservazioni della Terra (vedi "Un app store per i big data" , in GeoConnexion International, luglio/agosto 2020) ed è attualmente in corso nell'ambito di OGC Testbed-17.
Se siete interessati a conoscere l'approccio dell'OGC alla standardizzazione dell'accesso ai data cube, i membri dell'OGC possono seguire le prime fasi di sviluppo partecipando come osservatori al Testbed-17 dell'OGC . In alternativa, i membri dell'OGC possono unirsi al gruppo di lavoro Earth Observation Exploitation Platform Domain Working Group . I risultati dettagliati del workshop sono disponibili sulla pagina web del workshop OGC & GEO Towards Data Cube Interoperability.
Una versione di questo articolo è apparsa originariamente nel numero di luglio/agosto 2021 della rivista GeoConnexion International Magazine.
