Descrizione della Piattaforma ============================= L'intera catena operativa di **Radar-DPC** è sintetizzata nella figura seguente. .. image:: radar-dpc-schema.png :width: 80% :align: center :alt: Radar-DPC Schema Di seguito una descrizione *step by step* del flusso, con maggiori dettagli sui vari moduli. Step 1: Raccolta dati --------------------- .. image:: step1.png :align: center :width: 360 :alt: Raccolta dati I dati “raw” provenienti dalla rete radar provengono da siti gestiti oltre che dal Dipartimento, anche dalle Regioni, Enav e CNMCA. Ciascuno dei suddetti Enti ne cura, per i propri siti, l’attività di manutenzione ordinaria e straordinaria. Attraverso metodologie robuste e consolidate, i dati raw vengono acquisiti dal Dipartimento per effettuare processamenti finalizzati alla generazione di prodotti. Step 2: Elaborazioni del DPC ---------------------------- .. image:: step2.png :align: center :width: 360 :alt: Elaborazioni del DPC I dati Raw raccolti presso il DPC vengono processati mediante algoritmi che, a partire dai dati grezzi ricevuti dalle stazioni della rete meteo radar, generano dei prodotti visualizzabili su mappa. In particolare: * **VMI (Vertical Maximum Intensity)** - Aggiornamento 05 min * E’ un prodotto che rappresenta il valore massimo di riflettività [dBz] presente sulla verticale di ogni punto. Il VMI viene utilizzato per un monitoraggio generale, in quanto permette di distinguere le zone in cui sono in corso fenomeni di un certo rilievo e di classificarli in base alla loro tipologia (fronti, sistemi convettivi). * **HRD (Heavy Rain Detection)** - Aggiornamento 05 min * E’ un prodotto che ha l’obiettivo di individuare delle aree in cui sono in corso precipitazioni particolarmente intense, persistenti e/o di natura temporalesca a cui associare un Indice di Severità sulla base della combinazione di diversi misure/prodotti standard generati dalle varie catene operative presso il Dipartimento. * **SRI - Surface Rainfall Intencity** - Aggiornamento 05 min * E’ un prodotto elaborato attraverso specifiche catene operative sviluppate presso il Dipartimento, che ha l’obiettivo di fornire una stima dell’intensità di precipitazione al suolo (mm/h). * **SRT_1/3/6/12/24 h - Cumulata di precipitazione** - Aggiornamento 60 min * **SRT_1_** E’ un prodotto che rappresenta la cumulata di precipitazione (mm) nell’ultima ora sulla base dell’integrazione del dato radar SRI (sopra menzionato) su 1 ora e i dati della rete a terra. * Le altre cumulate (SRT_3h-6h-12h-24h) sono ottenute esclusivamente a partire dai dati “raw” della rete a terra provenienti dalle stazioni pluviometriche, disponibili nell’ambito della rete dei centri funzionali, e successivamente oggetto di elaborazione attraverso tecniche di interpolazione da parte del Dipartimento al fine di ottenere la distribuzione omogenea dell’informazione sul territorio sui diversi intervalli temporali. * **IR108 - Copertura nuvolosa** - Aggiornamento 05 min * Prodotto derivato da elaborazione del canale IR 10.8 di satelliti MSG (Meteosat Second Generation Images). * **TMP - Mappa delle Temperature [°C]** -  Aggiornamento 60 min * Prodotto che è ottenuto a partire dai dati “raw ”della rete a terra provenienti dalle stazioni termometriche, disponibili nell’ambito della rete dei centri funzionali, e successivamente oggetto di elaborazione attraverso tecniche di interpolazione da parte del Dipartimento al fine di ottenere la distribuzione omogenea dell’informazione sul territorio. * **LTG - Mappa dei Fulmini** - Aggiornamento 10 min * Il prodotto, fornito dal Aeronautica Militare - CNMCA, rappresenta una stima in tempo reale della frequenza assoluta di fulminazioni proveniente dalla rete LAMPINET * **WIND AMV - Direzione e intensità del vento in Quota** - Aggiornamento 20 min * Il prodotto rappresenta il campionamento dei valori puntuali contenuti nel prodotto MPEF (Meteorological Products Extraction Facility) denominato Atmospheric Motion Vector, su una griglia di 50x50 kmq * **RADAR** * Ubicazione dei siti. **Verde:** ON - **Rosso:** OFF Step 3: Trasferimento prodotti ------------------------------ .. image:: step3.png :align: center :width: 360px :alt: Trasferimento prodotti I prodotti generati vengono memorizzati in particolari locazioni, all'interno della rete del Dipartimento. E' importante osservare che i vari prodotti possono avere formati differenti. Ad esempio i prodotti VMI sono coperture *raster* in formato GeoTIFF, mentre i prodotti HRD sono *vettori* codificati in una collezione Shapefile (.shp, .shx, .prj, .dbf). A seconda del formato di dato, il prodotto viene sistematicamente trasferito nella opportuna directory. Step 4: Ingestione dati ----------------------- .. image:: step4.png :align: center :width: 360px :alt: Ingestione dati Il modulo *Core* della piattaforma *WIDE* si occupa della "organizzazione" dei prodotti generati tramite gli algoritmi del Dipartimento in apposita struttura dati di archiviazione. Questo processo viene anche detto *Ingestione dei dati*. Specifiche componenti software "osservano" le directory predisposte per l'ingestione di GeoTIFF e di Shapeifle dei diversi prodotti. Le logiche implementate implementano controlli affinchè le azioni di ingestione partano solo quando il file (o l'intera collezione di file, nel caso di shapefile) sia stato completamente trasferito. Essendo la frequenza di generazione dei prodotti molto elevata, sono inoltre implementate logiche di cancellazione, in modo da mantenere persistenti solo coperture e i vettori di una finestra temporale di 7 giorni. L'intervallo della finestra temporale da mantenere in persistenza può essere configurato. Ingestione di Shapefile ^^^^^^^^^^^^^^^^^^^^^^^ Nel caso in cui il prodotto sia in formato Shapefile (es. HRD), quando il modulo rileva il completamento del trasferimento dell'intera collezione shapfile, avvia un processo di memorizzazione delle informzioni in essa contenute in una Tabella PostGIS predisposta. Il timestamp dei vettori viene mantenuto in specifico attributo, in modo tale da consentire la configurzione dei servizi WMS e WMTS con il *vendor parameter TIME*. Ingestione di GeoTIFF ^^^^^^^^^^^^^^^^^^^^^ Nel caso in cui il prodotto sia in formato GeoTIFF (es. VMI), si è di fronte a una griglia di informazioni codificata come pixel/valore, la cui estensione spaziale (*Bounding Box*) è la medesima per ogni campione generato, mentre la discriminante tra campione e campione è il *timestemp* dell ostesso. Quando il modulo rileva il completamento del trasferimento del file, avvia un processo di memorizzazione delle informzioni in esso contenute: la copertura raster viene salvata in apposita area di storage, mentre in una Tabella PostGIS predisposta viene inserito un record che consente di associare ad un determinato timestamp la relativa copertura raster. Step 5: Configurazione dei servizi OGC -------------------------------------- .. image:: step5.png :align: center :width: 360px :alt: Configurazione automatica dei servizi I moduli di ingestione si occupano di verificare che i file relativi ad ogni campione memorizzato siano integri e completi e conseguentemente di memorizzare in apposita struttura dati predisposta per i diversi prodotti. Le strutture dati, implementate mediante PostGIS, vengono utilizzate come Data Stores per l'erogazione di servizi *OGC - Compliant* tramite GeoServer. Per i prodotti di natura vettoriale (es. HRD) la caratterizzazione temporale del campione è memorizzato in apposito attributo. I relativi servizi WMS e WMTS sono pertanto configurati su data store PostGIS, configurando la *time dimension* sull'attributo predisposto. Avendo i campioni dei prodotti una frequenza nota, la time dimension è configurata (e servita) mediante la definizione di un *Period Time (PT)*: ciò consente ad un client di inoltrare richieste di servizio sui campioni disponibili semplicemente incrementando il parametro *time* con calori multipli del *PT*. Le informazioni circa timestamp dei campioni disponibili e il time period sono disponibili nel documento di Capabilities del Server, come visibile nella porzione di WMS GetCapabilities response di seguito mostrato: .. code-block:: xml radar:hrd hrd ... ... 2018-08-31T00:00:00.000Z/2018-09-07T08:25:00.000Z/PT5M ... nell'esempio è possibile notare il valore di dafault, gli estremi inferiore e superiore dell'intervallo disponibile e la durata del Period Time (*PT5M - step di 5 minuti*). Nel caso in cui i prodotti siano di natura raster (es. VMI) viene adottata una logica di ingestione differente, avvalendosi dell' *Image Mosaic Plugin* di GeoServer. In particolare l'Image Mosaic viene utilizzato per creare uno mosaico di più coperture raster. Le coperture possono essere oganizzate non solo spazialmente ma anche su altre dimensioni, come tempo e elevazione. Nel caso in esame, l'area spaziale è fissa mentre la dimensione temporale è l'elemento che detramina il campione da servire. L'Image Mosaic si avvale di alcuni file di configurazione per gestire le dimensioni e le diverse proprietà del mosaico. In particolare il file *timeregex.properties* contenentiene un'espressione regolare da applicare al nome del file che viene utilizzata dall'indicizzatore per estrarre il valore temporale dal campione di copertura da servire come WMS o WMS in corrispondenza di un determinato valore del parametro Time della richieta. In questo modo è possibile gestire serie temporali di dati, afferenti a una stessa area di pertinenza. Step 6: Generazione cache on demand ----------------------------------- .. image:: step6.png :align: center :width: 300px :alt: Generazione cache on demand L'adozione di un server di mapping OGC compliant comporta che le mappe meteo dei prodotti radar possano essere servite tramite servizi web. I protocolli WMS e WMTS consetono infatti dieffettuare una richiesta in specifica area di uno specifico layer ad una specifica data. Il server si occupa di accedere ai dati memorizzati neglie archivi ed effettuare il rendering della immagine mappa nel formato e nel sistema di riferimenti richiesti. E' facile intuire che all'aumentare del numero di richieste simultanee il carico di lavoro per il rendering real-time delle immagini mappa diviene sempre più oneroso. Per tale motivo la piattaforma si avvale di un ulteriore modulo, *GeoWebCache* che consente di alimentare e mantenere una *Cache* delle tile che siano già state renderizzate in precedenza. La componente di *Geo-Caching* che si occupa di memorizzare map tiles già generati, rendendoli immediatamente disponibili a richieste corrispndenti, con evidente risparmio del costo di rendering da parte della Map Server. Questa componente è logicamente inserita nello stesso livello della Map Server, essendo dedicata alla riduzione dei tempi di risposta per richieste di servizi di mapping OWS. La componente di Geo Cache si occupa di Gestire una cache di Map Tiles che siano stati già generati (rendering da parte della Map Server) o mediante richieste già servite, o mediante operazioni di Seed effettuate in background appositamente per la popolazione della cache. L’utilizzo di una cache consente enormi risparmi nei tempi di risposta, evitando il costo di rendering al run time ogni volta che venga richiesto un map tile già precedentemente renderizzato. Il funzionamento della Geo Cache Infrastructure è il seguente: - Il Geo Cache Server riceve la richiesta di un Map Tile - Il Geo Cache Server controlla nel suo DataBase se esiste una entry relativa al Map Tile Richiesto In caso affermativo: - il Geo Cache Server accede allo storage in cui sono memorizzati i Map Tiles, recupera l’immagine d’interesse e la restituisce al client che l’ha richiesta In caso negativo: - il Geo Cache Server inoltra la richiesta alla Map Server Infrastructure, la quale effettua il rendering del Map Tile richiesto generando la relativa immagine - il Geo Cache Server riceve l’immagine generata e, prima di restituirla al client che l’ha richiesta, la memorizza nello storage e aggiunge l’entry corrispondente nel proprio DB. Step 7: Fruizione dei servizi ----------------------------- .. image:: step7.png :width: 80% :align: center :alt: Fruizione dei servizi La piattaforma **Radar-DPC** è strutturata per processare automaticamente i prodotti meteo-rarar del Dipartimento per la loro pubblicazione e cosnumo attraverso mappe web interattive. A tale scopo sono state utilizzate tecnologie open source che consentono la compatibilità con standard internazionali per lo scambio di dati georiferiti. La Piattaforma include ancehe un modulo di presentazione, ovvero una Applicazione Web attraverso cui è possibile visualizzare in mappe interattive i monitoraggi spazio-temporale delle grandezze meteo osservate tramite la rete radar. Maggiori informazioni sulla **Radar-DPC Web App** sono presenti al seguente :doc:`LINK <./app>` Naturalmente è possibile anche accedere, mediante applicazioni di terze parti, direttamente ai servizi WMS e WMTS, e poter così utilizzare le relative mappe all'interno altri aplicativi. Dettagli su come accedere direttamente ai servizi WMS e WMTS sono descritti al seguente :doc:`LINK <./services>` Step 8: Update delle immagini disponibili ----------------------------------------- Come già indicato in precedenza, i prodotti derivati dalle osservazioni radar hanno frequenze stabilite per cui il server che eroga i relativi servizi web di mapping annuncia nel docimento di getCapabilites il primo e l'ultimo campione, nonchè il *period time* per poter gestire gli step di avanzamento in caso di riproduzione di serie temporali. In aggiunta il modulo di ingestione dati è in grado di notficare l'acquisizione di un nuovo campione e la sua disponibilità come servizio web. Tale notifica viene effettuata mediante un messaggio *Web Socket*, per cui eventuali client in ascolto sul canale web socket (tra cui naturalmente la **Radar-DPC Web App**) possono ricevere la notifica e, con proprie logiche applicative, provvedere al corretto aggiornamento dei parametri di richiesta per l'oittenimento delle nuove sequenze aggiornate. .. toctree:: :maxdepth: 2 :caption: Contenuti