Negli ultimi anni, la quantit‘a di dati derivanti dallŠosservazione satellitare della Ter-ra (attTer-raverso il telerilevamento) ‘e aumentata notevolmente. Come ‘e possibile osser-vare nella Figura 1.7, infatti, il volume dei dati liberamente accessibili (provenienti dalle missioni Landsat-7, Landsat-8, MODIS, Sentinel-1, Sentinel-2 e Sentinel-32) ‘e passato da 0,5 PB nel 2015 a circa 4,25 PB nel 2019 (Volpini, 2021).
Figura 1.7. Volume annuale di dati liberamente accessibili prodotti da Landsat-7, Landsat-8, MODIS e le 3 missioni Sentinel (Soille et al., 2018).
Questo fenomeno di incremento del volume dei dati, chiaramente, ‘e avvenuto grazie ai progressi tecnologici e alle politiche di open data adottate dai governi e dalle agenzie spaziali. Gestire questi grandi insiemi di dati spaziali (che spesso superano le capacit‘a di memoria, archiviazione ed elaborazione dei personal computer e che hanno differenti risoluzioni spaziali, temporali e spettrali) ‘e divenuto complesso.
Per facilitare lŠaccesso e la manipolazione dei dati si ‘e reso necessario, dunque, sviluppare delle nuove soluzioni tecnologiche basate su ambienti di cloud computing (che sono offerti dai provider come servizi) e sui sistemi distribuiti. Questi ambienti hanno il vantaggio di essere altamente scalabili e mettono a disposizione database, strumenti per sviluppatori, spazi di archiviazione e servizi di rete.
2Landsat, Sentinel e MODIS sono alcune delle pi‘u importanti missioni satellitari per il telerilevamento della Terra.
Intuendo le potenzialit‘a di questa nuova tecnologia, la Commissione Europea ha sovvenzionato lo sviluppo di cinque piattaforme basate su cloud (Figura 1.8) note come DIAS (Data and Information Access Services). Queste piattaforme consentono
Figura 1.8.I DIAS e i relativi indirizzi web di accesso (Fonte: Copernicus DIAS).
un accesso centralizzato a tutti i dati e alle informazioni del programma Copernicus (compresi i dati rilevati dai satelliti Sentinel, i prodotti dei sei servizi operativi di Copernicus e gli strumenti cloud). Attraverso i DIAS, gli utenti possono scoprire, adoperare, elaborare e scaricare questi dati oppure possono sviluppare proprie ap-plicazioni e salvarle nel cloud, evitando la movimentazione e lŠelaborazione in locale di dati di dimensioni notevoli.
Figura 1.9.Schema di accesso ai dati grezzi acquisiti da diversi satelliti (Fonte: Copernicus DIAS).
In Figura 1.9 i DIAS vengono rappresentati dagli ŞInterface ServicesŤ, e viene mostrato come queste piattaforme consentono ad aziende, sviluppatori ed istituzioni di accedere alle informazioni contenute nei vari dataset e di realizzare degli speciĄci prodotti che vengono resi accessibili agli utenti Ąnali.
Tornando ad occuparci dei dati derivanti dal remote sensing, quelli utilizzati in letteratura (che coincidono con quelli trattati nel presente lavoro di tesi) sono nella maggior parte dei casi gratuitamente accessibili direttamente da appositi siti web, in molti casi dopo aver effettuato la necessaria registrazione. In alcuni casi, soprattutto per quanto riguarda dataset globali, non ‘e possibile scaricare i dataset nella loro interezza, in quanto questi possono essere molto grandi, ma ‘e necessario selezionare la zona di interesse. Questo pu‘o essere fatto, a seconda dei casi, sele-zionando zone predeĄnite (ad esempio un determinato stato) oppure delineando la zona di interesse in una mappa interattiva. In altri casi, ‘e disponibile unŠintegrazio-ne con Google Earth EngiunŠintegrazio-ne in modo che i dati siano direttamente accessibili anche tramite questa piattaforma. In generale, i dati satellitari possono essere utilizzati sia per il monitoraggio della deforestazione che per il calcolo del carbonio; nel primo caso, per‘o, sono disponibili molti pi‘u dati a causa della difficolt‘a nella stima della biomassa da remoto e della necessit‘a di calibrazione con dati presi a terra.
Una distinzione necessaria da fare riguarda i due tipi di dati satellitari: dati primari e dati secondari. Con il termine Şdati primariŤ intendiamo le immagini prese dai satelliti in varie bande spettrali, opportunamente pre-processate per la rimozione di rumore, nuvole, etc., che costituiscono, quindi, mappe dove ad ogni pixel ‘e associato un valore di riĆettanza spettrale. Con il termine Şdati secondariŤ, invece, identiĄchiamo le mappe derivate dai dati primari tramite ulteriori operazioni effettuate sulle bande spettrali, come le mappe degli indici di vegetazione, quelle di altitudine o quelle che descrivono la copertura del suolo.
Parlando di fonti dati, una delle principali per il progetto Forestry Analyzer ‘e la missione Copernicus (gi‘a descritta precedentemente). I satelliti che sono stati utiliz-zati per tale missione sono i seguenti: Sentinel-1, Sentinel-2, Sentinel-3, Sentinel-4, Sentinel-5, Sentinel-5P, Sentinel-6. I dati ottenuti da questi satelliti vengono pro-cessati e suddivisi in 6 diverse aree tematiche: land, marine, atmosphere, climate change, emergency management e security. Di particolare importanza per la stima della deforestazione ‘e il ŞCopernicus Land Monitoring ServiceŤ (CLMS), che for-nisce una serie temporale di prodotti bio-geoĄsici sullo stato e sullŠevoluzione del suolo terrestre, su scala globale e con risoluzione bassa (≥ 1 km), media (250-500 m) o alta (50-100 m).
I prodotti forniti dal CLMS sono suddivisi in quattro categorie: vegetazione, crio-sfera, energia e acqua. Si noti che i prodotti del CLMS sono prodotti secondari (o dati secondari), nel senso che sono forniti come dati gi‘a pre-processati a partire dai dati primari, ossia le immagini vere e proprie catturate dai satelliti. Oltre a questi, Copernicus mette a disposizione molti altri prodotti secondari; tra questi menzio-niamo il Copernicus EU-DEM, un ŞDigital Elevation ModelŤ (DEM) che mappa lŠaltitudine del terreno con una risoluzione orizzontale di 25 m e unŠaccuratezza verticale di +/-7 m. Sono, inoltre, presenti vari prodotti riguardanti speciĄcata-mente le foreste. Questi sono dati ad altissima risoluzione con copertura europea per gli anni 2012, 2015 e 2018. I prodotti presenti riguardano la densit‘a di copertura forestale, il tipo dominante di alberi (a foglia larga o conifere) e il tipo di foresta.
Per i primi due prodotti, inoltre, sono presenti anche le mappe del cambiamento di copertura.
In Tabella 1.1 sono elencate altre fonti dati (oltre quella della missione Co-pernicus) e, per ognuna di esse, le relative caratteristiche: se sono dati primari o
secondari, se per accedervi ‘e necessaria la registrazione al sito, la disponibilit‘a di una applicazione web per la visualizzazione interattiva, se i dati sono aggiornati in tempo reale (o quasi) e se sono presenti dati storici.
Fonte Tipo Registrazione Web
Copernicus Secondari S‘ı S‘ı S‘ı S‘ı
Sentinel Primari e
Sen12MS Secondari No No No S‘ı
Natural Earth Secondari No No No S‘ı
LandScan Secondari S‘ı No No S‘ı
WDPA Secondari No S‘ı No S‘ı
Earth Explorer Primari e secondari
S‘ı S‘ı S‘ı S‘ı
ESA Biomass Secondari No No No S‘ı
Global Forest Cano-py Height
Secondari No No No S‘ı
Nasa Fire Secondari No S‘ı S‘ı S‘ı
ESA WorldCover Secondari S‘ı/No S‘ı No S‘ı
Tropical Moist Fo-rests
Secondari No S‘ı No S‘ı
Tabella 1.1.Principali fonti di dati satellitari e loro caratteristiche.
1.2.3 Piattaforme IT
In questo paragrafo presenteremo tre piattaforme atte alla gestione e allŠanalisi di dati satellitari provenienti dal telerilevamento. Le tre tecnologie che verranno esaminate sono le seguenti:
• Open Data Cube (ODC);
• Google Earth Engine (GEE);
• SEPAL.
Per ciascuna piattaforma saranno indicate le principali caratteristiche, lŠarchi-tettura, i vari strumenti offerti, i metodi di gestione dei dati satellitari ed altre
funzionalit‘a fondamentali, che ci consentiranno, inĄne, di decretare qual ‘e la solu-zione migliore tra quelle analizzate e qual ‘e quella che soddisfa appieno i requisiti di progetto che verranno presentati nel prossimo capitolo.
La prima piattaforma che verr‘a presentata ‘e Open Data Cube (ODC). Questo
‘e un progetto di software di analisi e gestione dei dati geospaziali con il Ąne di fornire agli utenti degli strumenti in grado di sfruttare al meglio la ricchezza dei dati satellitari attraverso lŠanalisi di questi ultimi. Fondamentalmente, ODC ‘e un insieme di librerie Python che, attraverso lŠuso di un database PostgreSQL, consente la catalogazione e la gestione di enormi set di dati satellitari tramite un set di strumenti a riga di comando e unŠAPI Python. Il linguaggio di programmazione Python, infatti, si presta benissimo per lŠanalisi dei dati, per il machine learning e per tutte le necessit‘a del suddetto progetto grazie alle sue numerosissime librerie, alla sua leggibilit‘a, alla sua facilit‘a di utilizzo rispetto ad altri linguaggi ed al suo gran numero di risorse di reperibili online (composte da varie community, tutorial, articoli scientiĄci e altro). Come riportato sul sito ufficiale di Open Data Cube, lŠobiettivo di questo ambizioso progetto ‘e quello di aumentare lŠimpatto riguardo lŠutilizzo dei dati satellitari fornendo uno strumento aperto e liberamente accessibile.
Nella Figura 1.10 viene descritto lŠecosistema della piattaforma Open Data Cube.
Figura 1.10.Ecosistema di Open Data Cube
Il sistema ODC ‘e totalmente open source, ‘e gratuito per tutti e rilasciato sotto i termini liberali della licenza Apache 2.0. LŠiniziativa ODC ‘e supportata da 6 partner istituzionali, ovvero:
• Geoscience Australia (GA);
• NASA / Committee on Earth Observation Satellite (CEOS);
• United States Geological Survey (USGS);
• Commonwealth ScientiĄc and Industrial Research Organisation (CSIRO);
• Catapult Satellite Applications
• Analytical Mechanics Associates (AMA).
LŠelemento principale di questa piattaforma ‘e lŠODC Core e si occupa dellŠin-dicizzazione dei dati; esso, fondamentalmente, consiste in un insieme di script in Python (che catalogano i metadati attraverso il database PostgreSQL) e fornisce unŠAPI per lŠaccesso alle informazioni.
Osservando la Figura 1.11, invece, si riesce ancor di pi‘u a cogliere il meccanismo di funzionamento di ODC attraverso i suoi componenti fondamentali.
Figura 1.11.Diagramma delle componenti di una distribuzione ODC
Sulla sinistra troviamo la componente dati; in particolar modo, viene indicata la possibilit‘a che offre ODC di immagazzinare i dati satellitari sia in locale che in cloud. Nella parte centrale, dove troviamo lŠinfrastruttura, viene indicato il database che ODC sfrutta per lŠindicizzazione dei dati satellitari (PostgreSQL). Sulla destra dellŠimmagine, invece, vengono indicate le varie modalit‘a con le quali gli utilizzatori Ąnali possono utilizzare le funzionalit‘a del sistema ODC.
La piattaforma Open Data Cube, come mostrato in Figura 1.12, si colloca come livello intermedio tra i provider di dati satellitari e le applicazioni utilizzate dagli utenti per analizzare i dati.
Open Data Cube pu‘o essere distribuito su varie piattaforme di elaborazione. Le possibili soluzioni sono le seguenti:
• distribuzione locale (ad esempio, workstation di fascia alta);
• cloud (ad esempio, Amazon Web Services);
• infrastruttura High Performance Computing (ad esempio, NCI).
Scendendo ad un livello pi‘u tecnico, unŠimplementazione di ODC ‘e costituita da 3 componenti fondamentali:
• I dati sono solitamente basati su Ąle, sia in directory locali di GeoTIFF che in Ąle NetCDF; dunque, i dati possono essere tutto ci‘o che GDAL pu‘o leggere (inclusi i GeoTIF ottimizzati per il cloud archiviati su AWS S3).
• Per gli indici, ODC utilizza PostgreSQL come database per archiviare un elenco di prodotti (cio‘e raccolte di insiemi di dati che condividono lo stesso insieme
Figura 1.12.Dalla sorgente al risultato, passando per Open Data Cube
di misure e alcuni sottoinsiemi di metadati, ad esempio ŞLandsat 8 Analysis Ready DataŤ) e un dataset (aggregazione pi‘u piccola di una singola istanza di un prodotto, ad esempio una singola scena Landsat 8). LŠindice consente ad un utente di gestire dati senza dover sapere in modo speciĄco dove sono archiviati i Ąle richiesti e come accedervi; ci‘o permette di creare unŠastrazione a livello di dati che, chiaramente, agevola lŠutente nellŠutilizzo degli stessi.
• Il software al centro di ODC ‘e una libreria Python che consente agli utenti di indicizzare i dati (aggiungere record allŠindice), di inserire dati (ottimizzare i dati indicizzati per le prestazioni), di interrogare i dati (restituendo dati in un formato standard) e di svolgere una vasta gamma di altre funzioni relative alla gestione dei dati.
La grande potenzialit‘a di ODC, come ‘e stato possibile apprezzare Ąno ad ora,
‘e quella di sempliĄcare la gestione di dati di grande dimensione senza richiedere che questi ultimi vengano archiviati riducendo lo spostamento di grandi moli di dati. Ci‘o signiĄca che ‘e possibile creare un indirizzamento al repository di dati e indicizzare questi ultimi riducendo gli oneri di gestione di grandi raccolte di dati distribuiti.
In Figura 1.13 viene rappresentata lŠarchitettura di Open Data Cube. Come si evince da essa, vi sono 3 livelli architetturali:
• Data acquisition and inĆow: processo per raccogliere e preparare i dati prima di essere indicizzati.
• Data Cube Infrastructure: ‘e il nucleo principale di ODC in cui i dati EO vengono indicizzati, archiviati e consegnati agli utenti tramite lŠAPI Python.
• Data and Application Platform: raggruppa moduli applicativi ausiliari.
In origine, riferendoci alla storia e allŠorigine della gestione dei dati derivanti dal telerilevamento, le immagini satellitari venivano memorizzate e distribuite at-traverso grandi nastri magnetici. Nel 2011 Geoscience Australia ha lavorato con un certo numero di altre organizzazioni per copiare i dati Landsat che erano stati me-morizzati (sui suddetti nastri e in altre posizioni) su dischi Ąsici presso la National
Figura 1.13.Architettura di Open Data Cube
Computational Infrastructure, come parte del progetto ŞUnlocking the Landsat Ar-chiveŤ. Qualche tempo dopo ‘e stato sviluppato lŠAustralian Geoscience Data Cube (AGDC), uno strumento speciĄco Landsat in grado di migliorare lŠaccesso a questi archivi Landsat. Pi‘u recentemente, AGDC ‘e stato riscritto come AGDCv2. Questa versione, pi‘u recente, aveva in mente una serie di obiettivi che oggi sono i pilastri fondanti del progetto ODC. Nel 2017 AGDCv2 ‘e stato ribattezzato Open Data Cu-be e sono state istituite strutture di governance per garantire che il progetto potesse avere un supporto continuo a lungo termine.
Tornando a quello che oggi ‘e il progetto Ąnito e professionale di Open Data Cube, questŠultimo ha costruito importanti implementazioni operative in tre paesi e molti altri paesi sono in varie fasi di implementazione. In Figura 1.14 vengono riportate le installazioni principali che utilizzano ODC. Il campo dŠapplicazione di ODC ‘e orientato verso le grandi installazioni, come Digital Earth Australia, ma ci sono stati alcuni lavori recenti che mirano a rendere pi‘u user friendly lŠuso della piattaforma.
Ci‘o include implementazioni di riferimento che utilizzano Docker, sempliĄcando il processo di deploy. Inoltre, si sta lavorando su un ambiente sandbox JupyterHub il pi‘u possibile autoconsistente.
Gli ultimi traguardi raggiunti da ODC a livello tecnico (e, pi‘u speciĄcatamente,
Figura 1.14. Mappa riassuntiva delle varie implementazioni di Open Data Cube nel mondo
a livello di caricamento dei dati sulla piattaforma) sono principalmente due:
• In primo luogo, ‘e stato appurato che Cloud Optimised GeoTIFF (COG) ‘e un ottimo standard che consente di archiviare i dati su AWS S3 (o simili) e di accedere a piccole parti del Ąle senza la necessit‘a di scaricare lŠintero Ąle. Poich´e ODC utilizza Rasterio e GDAL per leggere i dati, ‘e possibile gestire i COG in modo nativo, e quindi ODC ‘e in grado di indicizzare i dati da S3. Ci‘o signiĄca che non ‘e necessario trasferire vaste raccolte di dati in unŠarea di lavoro locale:
tutto pu‘o essere trasmesso in streaming su richiesta.
• In secondo luogo, SpatioTemporal Asset Catalog (STAC) ‘e uno standard di metadati progettato per affiancarsi ai dati spaziali archiviati in un servizio cloud, al Ąne di fornire informazioni su quali dati sono disponibili in un catalogo e quali informazioni speciĄche sui dati sono necessarie per utilizzarli facilmente.
Mentre ODC non pu‘o ancora leggere STAC, sono in corso lavori per esplorare lŠuso dei Ąle STAC come fonte di informazioni per indicizzare i dati, e cŠ‘e un ulteriore potenziale per ODC di esporre una rappresentazione STAC del suo indice. A tal proposito, la community spinge moltissimo verso la soluzione che utilizza STAC per lŠindicizzazione dei dati e, per questo motivo, sta raccogliendo consensi positivi.
Il sito ufficiale di STAC ‘e il seguente: https://stacspec.org/
Il repository ufficiale di ODC-STAC sul Github ufficiale di ODC si trova al seguente indirizzo: https://github.com/opendatacube/odc-stac
La documentazione ufficiale di ODC-STAC si trova al seguente indirizzo: https:
//odc-stac.readthedocs.io/
Tornando sulla descrizione delle funzionalit‘a di ODC, i set di dati spaziali supportati da questŠultimo sono:
• Landsat 5 / 7 / 8 - ARD (surface reĆectance, USGS Collection-1, UTM projection, 30m).
• Landsat 5 / 7 / 8 - ARD (surface reĆectance, from LEDAPS and NBAR, Albers projection, 25-m).
• Sentinel-1 - ARD (gamma nought, 10m).
• Sentinel-1 - ARD (gamma nought, Albers projection, 12.5m).
• Sentinel-2 - Level-1C (MSI TOA reĆectance, Albers projection, 10/20/60m).
• ALOS-1/2 PALSAR Annual Mosaics - ARD (gamma nought, WGS84, 25m).
• ASTER Digital Elevation Model (DEM) - ARD (elevation).
• MODIS-MCD43 - ARD (BRDF Albedo, 16-Day L3 Global 500m).
Open Data Cube mette a disposizione degli utenti vari metodi di utilizzo, ognuno dei quali si presta alle diverse esigenze di ciascun utente. Le implementazioni che sono state implementate Ąno ad ora sono le seguenti:
• Open Data Cube core: ODC Core ‘e la soluzione implementativa di riferimento del progetto ODC dal momento che risulta pi‘u completa e funge come base per tutte le altre implementazioni. Installando ODC-core, infatti, si crea un ambiente Data Cube che pu‘o essere utilizzato per inserire dati ed eseguire processi di analisi. In Figura 1.15 possiamo vedere i vari step da seguire per lŠinstallazione e lŠinserimento dei dati su odc-core:
Figura 1.15.Pipeline di installazione ed indexing dei dati di Open Data Cube core.
CŠ‘e da notare che un aspetto mancante nella suddetta implementazione, ma che troviamo in ODC Web UI, ‘e sicuramente lŠinterfaccia utente. Qui, infatti, le fasi
di installazione ed indicizzazione non prevedono un supporto graĄco da parte della piattaforma e devono essere necessariamente svolte da riga di comando.
• Cube-in-a-Box: una soluzione pronta per lŠesecuzione ‘e denominata ŞODC Re-ference InstallŤ o, pi‘u comunemente, Cube-in-a-Box (CIAB). Questa implemen-tazione consiste in unŠimmagine docker contenente una istanza di ODC pronta per lŠuso che include nativamente lŠindicizzazione di dati Sentinel 2 di livello 2.
Anche in CIAB viene reso disponibile un Jupyter Notebook per permettere agli utenti di eseguire codice scritto in linguaggio Python.
• ODC Sandbox: questa alternativa permette di avere una sandbox di analisi senza dover installare alcuna componente dato che ‘e in cloud ed ‘e ottima per familia-rizzare con Open Data Cube. Dagli sviluppatori di ODC, questa soluzione viene descritta come Şpiattaforma dimostrativa, accessibile con un account GitHub o Google e gestita esternamente, perfetta da utilizzare prima che un utente in-stalli Open Data CubeŤ. A livello tecnico, ODC Sandbox ‘e un server notebook JupyterHub con Python e si basa sullŠindicizzazione della Global Collection 1 Landsat 8 AWS PDS. Il sistema in cloud fornisce agli utenti 2 core e 16 GB RAM.
• Open Data Cube Web UI ‘e unŠapplicazione web volta a visualizzare gli output dei codici in modo interattivo. LŠinterfaccia utente di Open Data Cube ‘e unŠap-plicazione Web Python per eseguire analisi su dati satellitari utilizzando Open Data Cube. Essa, quindi, agevola moltissimo la user experience con ODC for-nendo funzionalit‘a che aiutano a sempliĄcare la preparazione dei dati, nonch´e la loro elaborazione, visualizzazione ed esportazione, al Ąne di sfruttare il tutto per operare unŠanalisi completa sulle immagini satellitari della Terra. In poche parole, lŠinterfaccia utente consente di eseguire le analisi da unŠinterfaccia web.
Le tecnologie principali sulle quali si basa lŠinterfaccia utente sono: Django, Ce-lery + Redis, Open Data Cube, PostgreSQL, Apache / Mod WSGI, Bootstrap3.
LŠutilizzo di queste tecnologie fornisce una buona piattaforma di partenza per gli utenti dal momento che consente a questi ultimi di, accedere a vari dataset che abbiamo caricato, eseguire analisi personalizzate su aree e intervalli di tempo de-Ąniti dallŠutente, generare prodotti visivi (immagini) e dati (GeoTiff/NetCDF), fornire un facile accesso ai metadati e ai risultati delle analisi svolte.
• ODC + Google Earth Engine: questa soluzione implementativa, conosciuta anche con il nome ŞODC - Google SandboxŤ, consiste in unŠinterfaccia di programma-zione gratuita e aperta che collega gli utenti di ODC ai dataset di Google Earth Engine. Questo strumento consente agli utenti di eseguire algoritmi in linguag-gio Python utilizzando lŠenvironment notebook Colab di Google. Per utilizzare ODC con GEE ‘e necessario essere registrati come sviluppatori GEE e accettare di seguire i termini di servizio di Google per lŠutilizzo del loro prodotto.
In Figura 1.16 viene mostrato il funzionamento generale di questa soluzione implementativa appena descritta.
Per concludere la descrizione di questa prima tecnologia presentata, verranno analizzati, di seguito, i principali vantaggi e svantaggi di questŠultima.
In particolare, i principali vantaggi di ODC sono i seguenti:
• Astrazione dei dati: Open Data Cube, infatti, nasconde allŠutente i dettagli su come i dati vengono gestiti senza limitare la modalit‘a di accesso; questo,
Figura 1.16.Rappresentazione della soluzione implementativa che integra Google Earth Engine e Open Data Cube
chiaramente, porta lŠutente a lavorare ad un livello di astrazione pi‘u alto e, quindi, ad essere facilitato nellŠutilizzo dei dati. A livello tecnico, ODC imple-menta lŠastrazione dei dati attraverso lŠintroduzione di 2 concetti: ŞproductŤ e ŞdatasetŤ.
• Open governance: la piattaforma ODC, oltre che ad essere open source e a ren-dere disponibile il codice sorgente in repository aperti che consentono alla comu-nit‘a scientiĄca di partecipare in modo collaborativo al loro sviluppo, ‘e lŠunica che fornisce documenti divulgativi publici e che consente di creare o
• Open governance: la piattaforma ODC, oltre che ad essere open source e a ren-dere disponibile il codice sorgente in repository aperti che consentono alla comu-nit‘a scientiĄca di partecipare in modo collaborativo al loro sviluppo, ‘e lŠunica che fornisce documenti divulgativi publici e che consente di creare o