Spatial Data Infrastructure per l'Osservatorio Siccità
Un flusso coerente, dall’acquisizione dati alla distribuzione dell’informazione
Lo SDI (Spatial Data Infrastructure) alla base del DO si fonda sui due paradigmi Open Innovation e FAIR.
FAIR sta per: Findable, Accessible, Interoperable, Reusable.
Il concetto di Open Innovation, ha tre pilastri fondamentali:
- Open Source
- Open Data
- Open Access
Lo SDI, inoltre, risponde ad alcuni requisiti fondamentali: dati della ricerca open, flessibilità, scalabilità, reattività, bisogni e competenze specifici degli utenti.
L’user-oriented e process-based SDI del DO è focalizzato sul miglior utilizzo dei dati climatici ed ambientali per la valutazione della siccità e la loro trasformazione in informazione piuttosto che sul semplice data sharing.
I componenti tecnologici dello SDI del DO sono organizzati in una tipica architettura client-server ed interagiscono fra loro, dal processo di scarico dei dati dei providers, alla rappresentazione dei risultati per gli utenti finali, seguendo le linee guida generali OGC.
Data Cube
L'approccio del Data Cube spaziale multi-dimensionale permette l'acquisizione, immagazzinamento, accesso, analisi e uso di porzioni di dati intrinsecamente ordinati per condividerne gli attributi, uno dei quali dev'essere la loro geolocalizzazione (Strobl et al., 2017).
Standard OGC
Gli standard OGC (Open Geospatial Consortium) sono presenti in diversi elementi sviluppati nello SDI, dal data model, disegnato usando l'Unified Modeling Language (UML) (ISO TC/211), al software open source PostGIS.
Data Model
Il data model è sviluppato seguendo un approccio partecipativo fra i ricercatori coinvolti nel processo di raccolta ed analisi dei dati per l'implementazione dello schema applicativo.
Piattaforma Interoperabile
Per garantire l'interoperabilità fra dati spaziali e servizi della piattaforma, l'architettura generale dello SDI include tre servizi principali: il catalogo dei metadati, il servizio dati ed il servizio di processamento.
Il disegno dello SDI
Software open source e architettura a vari livelli per l’ottimizzazione del framework di monitoraggio del DO
Providers Layer Recupero dei dati di input
Framework Layer Siccità Gestione Metadati ed Elaborazione Dati Immagazzinati
Client-side Layer Disseminazione dei Risulati
I tre layer comunicano attraverso specifici servizi web REST (Representational State Transfer), seguendo il paradigma SOA.
Il paradigma REST, pur essendo solo marginalmente considerato nell’implementazione degli standard OGC (ovvero per il WMTS), è stato preferito rispetto al SOAP (Simple Object Access Protocol) perchè più leggero e meno client-side complesso da gestire da parte degli utenti.
Inoltre, i servizi web RESTful forniscono funzioni di estrazione e scarico dati efficaci e altamente flessibili.
Il Providers Layer ha il compito di gestire i dati di input provenienti da fonti diverse (piogge CHIRPS, e immagini MODIS di LST, NDVI e EVI) ed archiviarli nel Geodatabase (GeoDB), implementato nel Framework Layer Siccità.
I formati dati OGC attualemnte supportati dallo SDI sono il NetCDF per il dataset CHIRPS di pioggia ed il Well-Known Text (WKT) per i dati vettoriali usati per le funzioni di estrazione ed elaborazione.
I dati satellitari MODIS sono in formato HDF-EOS (Hierarchical Data Format-Earth Observing Systems), uno standard approvato e raccomandato nell’utilizzo negli Earth Science Data Systems della NASA.
Specifici script Bash sono stati sviluppati per lo scarico e la preparazione dei dati di input prima dell’archiviazione nel GeoDB.
Librerie GDAL (Geospatial Data Abstraction Library) e funzioni PostGIS di riproiezione spaziale, sezionamento ed immagazzinamento vengono utilizzate per migliorare le performance del GeoDB e per armonizzare i dataset con il data model.
Tutti i dataset sono riproietattati in un sistema di riferimento comune ed ampiamente usato: l’EPSG:4326 (che corrisponde al sistema Latlong, WGS84). Gli stessi script Bash chiamano servizi web RESTful forniti dal Livello Framework per immagazzinare i datasets nel GeoDB.
Un aggiornamento continuo dei dati di input è garantito da un cron daemon (crontab file) che lancia gli script automaticamente.
Il Framework Layer Siccità (B) è il componente principale dell’architettura SDI del DO, nel quale il database PostgreSQL rappresenta il Data Cube, ovvero l’ambiente unico per l’immagazzinamento e l’elaborazione dei dati. Allo stato attuale di implementazione, le query di elaborazione, lavorando con Servizi Web REST invece che SOAP, non seguono completamente le specifiche OGC WPS, ma sono state implementate seguendo le linee guida OGC per lo sviluppo di SDI interoperabili.
Tutti i servizi permettono l’immagazzinamento di nuovi dati, mentre i processi di recupero ed elaborazione sono sviluppati localmente usando il paradigma REST e chiamati attraverso semplici operazioni HTTP GET e POST. PostgreSQL è utilizzato all’interno del Data Cube per immagazzinare i dati di input (pioggia, LST, NDVI, EVI), per effettuare tutte le procedure di elaborazione (query, elaborazione degli indici, operazioni statistiche, ecc.), e per generare i dati intermedi (LSTmin, LSTmax, NDVImin, NDVImax, EVImin, EVImax) e le immagini di output (SPI, TCI, VCI, E-VCI, VHI, E-VHI) in diversi formati (GeoTIFF, PNG, ASCII Grid).
Sebbene tutti gli indici siano calcolati in PostgreSQL, la diversa complessità di calcolo degli indici di vegetazione e di pioggia ha obbligato l’uso di librerie differenti.
TCI e VCI, infatti, sono il risultato di semplici operazioni aritmetiche che possono essere fatte direttamente in PL/pgSQL sfruttando con successo le caratteristiche delle librerie PostGIS.
L’indice SPI, invece, è basato su funzioni statistiche più complesse (fitting di una distribuzione di probabilità Gamma, trasformata in una variabile Gaussiana standard). Per questo motivo, l’elaborazione dello SPI è stata implementata integrando nella libreria PostGIS una specifica libreria R.
L’integrazione fra il motore R e PostGIS è resa possibile grazie a PL/R, il wrapper R per PostgreSQL.
Un SDI process-based dovrebbe enfatizzare la comunicazione dell’informazione per poter raggiungere un ampio raggio di utenti e facilitare una pianificazione efficace.
I servizi web implementati nel Client-side Layer (C) supportano lo sviluppo di applicazioni personalizzate per la disseminazione dei risultati e la gestione dei servizi.
Applicazioni client personalizzate vengono sviluppate seguendo i bisogni specifici degli utenti (ricercatori, professionisti, amministrazioni pubbliche e la comunità) approfittando dei servizi interoperabili forniti dal Framework Layer Siccità.
Le funzioni API (Application Programming Interface) RESTful del Framework Layer Siccità permettono:
- di creare applicazioni WebGIS, website personalizzati e servizi che richiedono dati dello SDI del DO;
- di sviluppare un plug-in per altre applicazioni desktop GIS come QGIS o ArcGIS;
- di condividere ed integrare i dati del DO con altri SDI interoperabili.
I servizi del Framework Layer
Dati spaziali pronti per essere riutilizzati da qualsiasi applicazione client di terze parti
Il Framework Layer fornisce anche un set di servizi web RESTful, sviluppati usando JAX-RS (API Java per servizi web RESTful), per il recupero dei dati immagazzinati (input, dati intermedi e output) e per gestire le operazioni geospaziali sviluppate con PL/pgSQL (l’estrazione di porzioni di raster a partire da un determinato poligono, le statistiche di base e il lancio di modelli).
La piattaforma open source CKAN (Comprehensive Knowledge Archive Network) e il web server di pubblicazione dei dati GeoServer sono usati rispettivamente per arricchire il catalogo dei metadati e pubblicare i dati e i metadati. CKAN supporta la codifica ISO 19139 (Geographic information – Metadata – XML schema implementation) per la descrizione dei metadati ed è anche in grado di gestire gli standard OGC CSW e WMS.
