CNR-IBIMET climateservices.it

SDI per l'Osservatorio Siccità

Un flusso coerente, dall’acquisizione dati alla distribuzione dell’informazione

Lo SDI alla base del DO si fonda sul concetto di Open Innovation, che si fonda su tre pilastri fondamentali:

  • Open Source
  • Open Data
  • Open Access

Lo SDI, inoltre, risponde ad alcuni requisiti fondamentali: dati della ricerca open, flessibilità, scalabilità, reattività e bisogni 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.

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 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 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 sono 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 sevizi del Framework Layer

Dati spaziali pronti per essere riutilizzati da qualsiasi applicazione client di terze parti

API RESTful

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).

Open Data

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.

Il progetto Osservatorio Siccità: una breve scheda