TESSUTO DIGITALE METROPOLITANO - PROGETTO
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
P ROGETTO
T ESSUTO D IGITALE M ETROPOLITANO
POR FESR 2014-2020, Azione 1.2.2
Progetto Complesso area ICT della S3
Deliverable 2.2 – P ORTALE INTEGRATO DI PROGETTO ( VERSIONE INTERMEDIA )
Data di consegna prevista: 6/2021 Data di consegna effettiva: 6/2021
Natura: Rapporto Versione: 1.0
Livello di Disseminazione: (PU)
Sommario
TDM è un progetto collaborativo tra CRS4 e Università di Cagliari che combina attività di
ricerca, sviluppo, sperimentazione e formazione nel campo dell’informatica urbana. Questo
deliverable descrive il portale integrato di progetto nella sua versione intermedia. Il portale
rappresenta in maniera integrata ed organica sia i risultati che le attività legate al progetto ed i
progressi ad esso correlati.
Redazione
Nome Partner Data
Autore Carlo Impagliazzo CRS4 04/06/2021
Approvato da Enrico Gobbetti CRS4 04/06/2021
Storia e contributi
Vers. Data Commento Autori
V0.1 13/05/2021 Primo draft C. Impagliazzo
V0.2 25/05/2021 Aggiornamenti abstract, introduzione E. Gobbetti
e collegamenti con altri deliverables
V0.2 03/06/2021 Aggiornamento e pulizia E. Gobbetti e C. Impagliazzo
V1.0 04/06/2021 Versione completa E. Gobbetti e C. Impagliazzo
Indice
1 Introduzione 5
2 L’ecosistema dei portali TDM 6
3 Portale principale 7
3.1 Descrizione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Tematismo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3 Struttura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4 Contenuti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.5 Plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.6 Summer Schools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4 Portale Demo 15
4.1 Descrizione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2 Implementazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.1 HowTo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3 Applicazioni demo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3.1 Meteo e Radar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3.2 Fotovoltaico e Sensori Elettrici . . . . . . . . . . . . . . . . . . . . . 19
4.3.3 Previsione consumi elettrici, generazione da impianto fotovoltaico,
piattaforma pianificazione RESS-BESS . . . . . . . . . . . . . . . . 20
4.3.4 Previsione BOLAM . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.3.5 Confronto Temperature da sensori e da modelli . . . . . . . . . . . . 22
4.3.6 Monitoraggio Ambienti Indoor . . . . . . . . . . . . . . . . . . . . . 22
5 GRAFANA 24
5.1 Descrizione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6 DATA e REST 26
6.1 Portale CKAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.2 Accesso ai dati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
7 Conclusioni 30
4
1 Introduzione
Uno degli scopi del progetto TDM è quello di divulgare e disseminare l’informazione, i dati
e le metodologie di elaborazione di grosse moli di dati in uno scenario cittadino, toccando
diverse tematiche e discipline molto diverse.
Al fine di presentare in maniera integrata ed organica sia i risultati che le attività legate al
progetto ed i progressi ad esso correlati sorge l’esigenza di uno strumento che possa presen-
tarsi come una vetrina e riferimento, un unico punto in grado di convogliare sia informazioni
scienfiche che divulgative e documentative ma anche come rimando a strumenti operativi.
In questo scenario si parla quindi di ecosistema proprio per racchiudere un insieme di stru-
menti atti a soddisfare i suddetti requisiti, tra questi spicca il portale istituzionale di progetto
che si occupa proprio della parte divulgativa e documentativa e che smista l’utente verso i
servizi di interesse.
Il portale cosı̀ creato è pensato quindi per fornire una visualizzazione coerente su diversi
dispositivi, siano essi computer che dispositivi mobili.
In questo deliverable presentiamo i punti salienti del portale, nella sua versione intermedia, a
un anno dalla conclusione del progetto.
Il report è organizzato come segue:
• al Capitolo 2 presentiamo la struttura generale dell’ecosistema dei portali TDM e
l’articolazione in sottoportali dedicati ad aspetti specifici.
• al Capitolo 3 descriviamo il principale portale di progetto, in cui risiedono le do-
cumentazioni di progetto, gli aggiornamenti sulle attività ed i riferimenti agli altri
sottoportali.
• al Capitolo 4 dettagliamo il contenuto del portale demo, dove sono raccolti i vari
dimostrativi di progetto.
• al Capitolo 5 dettagliamo la sezione web Grafana del portale di progetto, che fornisce
ai visitatori un esempio delle possibilità di rappresentazione dei dati raccolti attraverso
i sensori, mostrandoli in maniera veloce e intuitiva i dati raccolti in modalità grafica.
• al Capitolo 6 descriviamo i portali dedicati al dispacciamento dei dati, che forniscono
un data source Open Data e una versione interrogabile tramite API che fornisce dati
processati e relativi descrittori.
Per ognuno dei portali, questo documento fornisce una visione d’insieme delle scelte che sono
state prese per il loro design, una descrizione dei vari software di base che li implementa-
no e una visione del loro stato attuale. Tutti i portali sono raggiungibili attraverso il punto
d’ingresso principale http://www.tdm-project.it.
5
2 L’ecosistema dei portali TDM
Il progetto TDM richiede una vetrina espositiva articolata su più fronti per soddisfare le diverse
necessità di progetto. Pur essendo interfacce differenti e con modalità di fruizione distinte,
possiamo definirle “portali” in quanto attraverso essi vengono veicolate i dati in varie modalità.
Il portale open data descritto in questo documento è pienamente integrato, con si vedrà, in
questo ecosistema.
• Il portale DOC è il landing site del progetto, più comunemente noto come WWW. Con-
tiene aggiornamenti, descrizioni ed approfondimenti sugli aspetti cardine del progetto,
documentazione e deliverable.
• DATA è il data source degli Open Data. Qui sono esposti i vari file che vengono prodotti
dall’infrastruttura interna di calcolo del TDM o dalle varie sorgenti che vi confluiscono.
Questo portale può essere usato come riferimento per gli indici verso i dati esposti dal
portale seguente.
• REST è il data source dei dati processati. Da qui è possibile scaricare file e descrittori
che definiscono un catalogo di dati
• DEMO la vetrina del progetto. Qui sono ospitate le informazioni sui dati, varie demo,
il visualizzatore e piccole guide su come accedere direttamente ai dati
• GRAFANA è il visualizzatore di dati realtime della sensoristica che alimenta il progetto
Tutti i portali citati sono raggiungibili abbinando
il nome ad uno dei domini di progetto, ossia:
• tdm-project.it
• tdm-project.com
• tdm-project.org
Partendo dal portale DOC è possibile raggiungere
gli altri portali passando dalla sezione :
“Risultati” sotto la voce “Demo e software“.
Figura 2.1: Schema portali.
6
3 Portale principale
3.1 Descrizione
Il portale precedentemente denominato DOC è il principale portale di progetto, qui risiedo-
no le documentazioni di progetto, gli aggiornamenti sulle attività ed i riferimenti agli altri
sottoportali.
I requisiti di partenza erano abbastanza standard per la costruzione di un portale di progetto e
quindi:
• facilmente mantenibile, aggiornabile, integrabile con nuovi contributi
• multi-utente
• multi-lingue
• tecnicamente pensato per essere mobile first
• che possa agevolmente fare da contenitore per documentazione e file in generale
• che usi solo strumenti Open Source
Essendo un profilo standard e con un nume-
ro di accessi ipotizzabile abbastanza contenuto
non sono necessari meccanismi di repliche atti-
ve e/o tecniche di high availability come sistemi
master-master o clustering.
La scelta delle tecnologie è quindi ricaduta prin-
cipalmente su una piattaforma LAMP classica (
Linux, Apache, Mysql, PHP ) che potesse fare da
fondamenta per un sistema CMS Open source in
grado di essere facilmente mantenibile, che fosse
versatile e che avesse una solida comunità al fi-
ne di garantire effetti di lock-in tecnologico o di
mancanza di aggiornamenti. Figura 3.1: Portale di progetto.
La scelta non poteva che andare quindi verso
una ristretta cerchia di soluzioni da cui attingere
Wordpress, questo è una piattaforma software di ”personal publishing” e content management
system (CMS) Open Source con licenza GPLv2 che consente la creazione e distribuzione di un
sito Internet formato da contenuti testuali o multimediali, facilmente gestibili ed aggiornabili
in maniera dinamica.
Inoltre permette di gestire contenuti, traduzioni, media, flussi di lavoro ed utenti in maniera
snella e flessibile attraverso l’interfaccia web.
7
Deliverable 2.2 (PUBLIC) TDM - POR FESR 2014-2020/A1.2.2
Wordpress è un sistema modulare per molti aspetti del frontend su cui è possibile lavorare
nel backend, moduli come i temi o i plugins, i moduli sono editabili, integrabili ed estendibili
ed infatti sono stati realizzati dei plugin e delle personalizzazioni tematiche specifiche per il
progetto.
Attualmente le versioni usate sono:
• Apache
URL: https://httpd.apache.org/
Release: 2.4.29
• PHP
URL: https://www.php.net/
Release: 7.2.24
• MySQL
URL: https://www.mysql.com/
Release: 5.7
• Wordpress
URL: https://wordpress.org/download/
Release: 5.3.8
3.2 Tematismo
Nella filosofia di costruzione del sito l’intelaiatura delle pagine si basa sui template fornito
da un tema, in questo caso si è scelta una base liberamente disponibile rilasciata con licenza
GPLv2 su cui fare le personalizzazioni e la costruzione del tema figlio, il tema di base è il
Vantage.
La best practice in questo caso prevede di adottare un tema base e tramite un plugin ( Child
Themify ) creare un tema derivato su cui applicare le modifiche e le personalizzazioni, so-
stanzialmente si crea il delta e lo si memorizza. Questo approccio consente di svincolarsi da
alcuni problemi che possono sorgere in fase di aggiornamento del tema base, sovente ci si
trova ad innestare blocchi di codice Javascript o personalizzazioni di stile direttamente nei file
del tema, farlo direttamente sulla radice base vuol dire che in caso di aggiornamenti, anche
accidentali, queste informazioni andrebbero perse.
Il footer del tema e’ costruito nel rispetto delle linee guida in tema di estetica per i progetti
POR FESR 2014-2020.
Il tema scelto si basa sul framework Bootstrap per poter perseguire l’obiettivo della respon-
sività, Bootstrap è infatti una raccolta di strumenti grafici, stilistici e di impaginazione che
permettono di avere a disposizione una gran quantità di funzionalità e di stili modificabili e
adattabili a seconda delle nostre esigenze. Il suo utilizzo risulta molto versatile, in quanto è
compatibile con tutte le ultime versioni dei principali browser. La sua principale funzione è
6/2021 8
Deliverable 2.2 (PUBLIC) TDM - POR FESR 2014-2020/A1.2.2
il responsive web design, ed è in grado di adattarsi dinamicamente a seconda della grandez-
za e delle caratteristiche del dispositivo utilizzato. Questa raccolta di strumentazione di tipo
grafico si pone, perciò, come una libreria multidispositivo e multipiattaforma.
Anche Bootstrap possiede una licenza Open, nello specifico la MIT.
Attualmente la versione usata è:
• Bootstrap
URL: https://getbootstrap.com/
Release: 3.3.7
Il tema è stato poi mutuato dagli altri sistemi web che compongono l’ecosistema nonostante
alcuni di essi abbiano una tecnologia implementativa differente, in alcuni casi è stato creato
un pacchetto di mockup con la struttura HTML+CSS necessaria per riscostruire il tema su
questi portali, in alcuni casi si è lavorato solo con lo stile CSS per avvicinare il Look&Feel del
portale centrale.
6/2021 9
Deliverable 2.2 (PUBLIC) TDM - POR FESR 2014-2020/A1.2.2
3.3 Struttura
Il primo aspetto che caratterizza il portale DOC è l’organizzazione della griglia delle
informazioni, come da immagine 3.2 avremo 5 aree :
Figura 3.2: Wireframe della Home page del portale
1. Area dell’header dedicata al Logo e sulla destra le icone per scegliere la localizzazione
2. Area dell’header dedicata al menu
3. Area dedicata a sottomenù contestuali alla pagina selezionata o slider delle news
4. Area dedicata ai contenuti
5. Footer con vari Logo dei principali attori di progetto
Per ogni pagina in cui sono presenti contemporaneamente il box 3 ed il box 4 il rapporto è
di 25% e 75% della larghezza del contenitore dentro cui si attestano e quindi rispetto alla
larghezza totale della pagina.
In questo modo è possibile articolare agevolmente la navigazione su più livelli tematici in
base al menu selezionato, a seconda della pagina ci potrà essere un sottomenù di navigazione
all’interno della pagina.
6/2021 10
Deliverable 2.2 (PUBLIC) TDM - POR FESR 2014-2020/A1.2.2
Figura 3.3: Menu del portale
Come da immagine 3.3 avremo:
• Home
Questa è la landing page del progetto, il box 3 contiene uno slider con le principali
novità ed eventi mentre nel box 2 c’è una descrizione del progetto.
• Obiettivi
In questa sezione sono descritti gli obiettivi operativi del progetto TDM, il box 3 contie-
ne i riferimenti ai principali tematismi del progetto, ossia sensoristica, big data, ambien-
te, energia, visualizzazione grosse quantità di dati. Infine c’è il riferimento alle attività
delle scuole di formazione che vengono organizzate durante il corso del progetto.
• Partner
In questa sezione sono elencati i principali partner facenti parte la compagine di proget-
to, sia in termini di gruppi di lavoro interni al CRS4 sia Università di Cagliari, nel box
3 c’è un riferimento alla lista dei principali responsabili di progetto.
• Risultati
La sezione contiene i principali risultati del progetto in termini di documenti pubblici,
pubblicazioni, presentazioni, software e demo rilasciate dal progetto, nel box 3 ci sono
i riferimenti alle specifiche sezioni da cui è possibile scaricare il materiale.
• Notizie & Eventi
In questa sezione sono collegate le notizie relative al progetto, annunci ed avvisi di
partecipazione ad eventi.
• Documentazione
In questa sezione c’è una raccolta della documentazione pubblica preparata nel qua-
dro del progetto. Vi si possono trovare informazioni generali, survey, link a standard
pertinenti e qualsiasi altra informazione che abbia un interesse per un ampio pubblico.
• Contatti
In questa sezione ci sono i contatti dei principali responsabili del progetto.
6/2021 11Deliverable 2.2 (PUBLIC) TDM - POR FESR 2014-2020/A1.2.2
3.4 Contenuti
Un’area di particolare rilevanza è data dai contenuti creati dal progetto e messi a disposizione
e dalle attività portate avanti.
Nella sezione Risultati, come già accennato, sono scaricabili documenti quali pubblicazioni,
presentazioni e sofware.
(a) Deliverables (b) Demo e software
Nella sezione Deliverables pubblici sono raccolti tutti i rapporti tecnici pubblici inerenti al
progetto, sia di carattere tecnico che scientifico. Ogni file scaricabile è un rapporto che testi-
monia l’avanzamento del progetto in una delle sue varie fasi e quindi offre una possibilità di
diffusione e disseminazione o genericamente una possibilità di trasferimento della conoscenza.
Nella sezione Demo e Software si possono trovare i riferimenti per il software di edge gateway,
sia una breve descrizione che il link per scaricarlo. Sono inoltre presenti i riferimenti per
raggiungere i vari portali che compongono l’ecosistema.
(a) Presentazioni (b) Pubblicazioni
Nella sezione Presentazioni si possono trovare i materiali prodotti in occasione dei diversi
meeting, seminari, convegni.
6/2021 12Deliverable 2.2 (PUBLIC) TDM - POR FESR 2014-2020/A1.2.2
Nella sezione Pubblicazioni si possono trovare le pubblicazioni relative alle varie attività di
progetto.
Un’altra sezione di contenuti divulgativi è quella della Documentazione, qui è possibile trovare
degli articoli di taglio divulgativo su:
• contesto di riferimento del progetto, OASC e Smart Cities
• sensoristica per l’energia, riferimenti sullo stato dell’arte ed approfondimenti sui sensori
più interessanti
• sensoristica per il monitoraggio ambientale, panoramica di alcune delle soluzioni più
promettenti per il monitoraggio della qualità dell’aria
• panoramica sullo stato dell’arte dei dispositivi mobili con focus sulla capacità di
elaborazione per la grafica ed analisi del trend futuro
3.5 Plugins
Wordpress è un framework modulare a cui è possibile collegare diversi plungins a cui de-
legare specifici task, in questa sezione verranno evidenziati alcuni che rappresentano alcune
funzionalità chiave:
• Child Themify
Child Themify è il plugin che si occupa di clonare un tema al fine di proporre una
versione sicura e modificabile
• Login Recaptcha
Una delle tecniche più classiche per guadagnare malevolmente gli accessi ad un sito web
è quella dell’iterazione a forza bruta, questo plugin crea delle maschere che ne rendono
molto difficile l’applicabilità e quindi aumentando la sicurezza.
• Memphis Documents Library
Questo plugin consente di gestire il repository della documentazione e dei file scarica-
bili, al fine di abbracciare meglio le esigenze del progetto sono state fatte alcune modi-
fiche al codice, alcune di essere sono state proposte al maintainer ed integrate in alcune
versioni.
• Polylang
Questo è il plugin che si occupa di gestire uno degli aspetti più ostici del sito ossia la
gestione multilingua sia dei contenuti sia del comportamento del portale in funzione
della lingua impostata del browser.
3.6 Summer Schools
Sempre usando lo stesso stack software sono stati creati due sotto portali dedicati alle summer
school, la filosofia rimane invariata e quindi sono destinati ad ospitare notizie, materiali e
6/2021 13Deliverable 2.2 (PUBLIC) TDM - POR FESR 2014-2020/A1.2.2
cronoprogramma delle relative scuole di formazione organizzate mantenendo quindi sempre
gli stessi principi e requisiti.
(a) Summer School 2019 (b) Summer School 2021
Figura 3.6: Portali delle Summer School
La differenza sostanziale dal punto di vista estetico sono l’header modificato per calzare me-
glio le aspettative del contesto e la costruzione delle pagine, in questo caso il box 3 ed il box
4 sono fusi in un’unica riga venendo a mancare la necessità di navigazione in sotto sezioni.
Al riguardo sono stati registrati 3 sottodomini :
• school2019.tdm-project.*
• school2021.tdm-project.*
• school.tdm-project.*
dove .* è qui usato come placeholder di convenzione per indicare che il sottodominio è valido
per i domini di primo livello .it , .org e .com.
L’ultimo sottodominio è funzionale per indicare l’edizione in corso o recentemente conclusasi,
le richieste pervenute a questo sottodominio vengono automaticamente redirette al sottodomi-
nio in questione. In questo modo è possibile tenere traccia di tutte le edizioni, dei relativi
materiali sempre a disposizione e dell’edizione dell’evento più recente.
6/2021 144 Portale Demo
4.1 Descrizione
Il portale demo è indipendente dagli altri portali
ed è collocato a valle degli altri rispetto all’archi-
tettura interna, in questo modo i dati di cui usu-
fruisce per i visualizzatori possono arrivare in ma-
niera indipendente dall’infrastruttura interna. Lo
scopo del portale è quello di fare da contenitore
per degli esempi di utilizzo e fornisce esso stes-
so un esempio di utilizzo dell’infrastruttura sot-
tostante in quanto si alimenta con dati degli altri
portali.
Essendo un portale dedicato alle dimostrazioni e
quindi essenzialmente un ponte tra i dati e lo stra-
to applicativo cambia anche la filosofia con cui
è stato costruito, rimane la necessità di una vi- Figura 4.1: Portale Demo
sualizzazione responsiva adattabile a dispositivi
di varia natura e grandezza.
La fruizione del portale e’ pubblica cosı̀ come i pezzi di codice ospitati sono liberamente
usabili. Dal punto di vista estetico l’ossatura del portale DEMO ricalca quella del portale
DOC già esistente, principalmente quindi con un header composto da logo di progetto seguito
da una barra orizzontale con menu. Sotto l’header lo schema prevede il container del tipo di
informazione che occorre mostrare nella pagina.
Il tematismo riprende quello del sito principale DOC, in questo caso però i box 3 e 4 sono fusi
in un unico box contenitore per rendere più ampio lo spazio di visualizzazione del contenuto
applicativo.
Il footer e’ costruito nel rispetto delle linee guida in tema di estetica per i progetti POR-FESR
2014-2020
In questa fase di progetto sono previste le seguenti voci di menu:
• Home
• Demo
• Opendata
Nella pagina HOME il contenuto è descrittivo del portale, spiega come è articolato lo stesso e
cita gli esempi che esso contiene.
15Deliverable 2.2 (PUBLIC) TDM - POR FESR 2014-2020/A1.2.2 Le informazioni di questa pagina sono di na- tura documentativa e non strettamente tecnica, può essere considerata come la landing page di presentazione. In basso alla pagina è presente uno slider con un accesso rapido alle applicazioni demo ospitate. Figura 4.2: Mockup header Il menu contiene la voce Opendata che e’ un ri- mando ad una pagina intermedia di presentazione per il portale DATA, dentro questa pagina c’e’ una parte descrittiva su cosa siano gli Open Data ed il link al portale. Sempre nel menu superiore si trova la voce ”Demo”, questo è un link verso una pagina in cui vengono elencati i principali casi dimostrativi sia con dei contenuti descrittivi per gli stessi. Il me- nu è dropdown e presenta anche la tendina da cui è possibile raggiungere velocemente i singoli ca- si d’esempio, siano questi interni al portale o link Figura 4.3: Mockup menu ad applicazioni residenti esternamente. In questa pagina ci sono anche i riferimenti a alcuni script che mostrano un possibile accesso ed uso dei contenuti del portale DATA. La voce ”Eventi meteo”, più genericamente rap- presentabile anche come ”Eventi”, apre una pa- gina con la lista degli eventi meteo di un certo rilievo che hanno interessato l’area di studio per la sperimentazione. La pagina in questione è ca- ricata direttamente usando come alimentazione i dati provenienti dal portale DATA ed effettuan- do una scrematura delle informazioni sulle risorse che ogni singolo dataset per evento mette a dispo- Figura 4.4: Mockup page sizione. Da questa sezione è possibile passare al visualizzatore dell’evento correlato. 4.2 Implementazione Un sistema come Wordpress è utilissimo come gestore di contenuti ma risulta ostico se lo si pensa come centro di aggregazione dati ed al tempo stesso come applicazione dimostrativo, questo per via di diversi sistemi di protezione atti a rendere l’infrastruttura più stabile e meno soggetta all’essere inquinata, intenzionalmente o meno, da sofware malevoli o fallaci. Per questo motivo al fine di poter coniugare una flessibilità di piattaforma dimostrativa con la fruizione dei contenuti è stata costruita l’infrastruttura usando dei sistemi che, grazie all’ac- cesso ad un livello più basso, possono fornire una struttura di templating del codice HTML e delle comode API verso le altre strutture, il portale ”DATA” in primis. 6/2021 16
Deliverable 2.2 (PUBLIC) TDM - POR FESR 2014-2020/A1.2.2
La scelta è ricaduta su Flask come piattaforma di sviluppo su cui costruire l’applicazione DE-
MO. Flask è un ”micro-framework” perché ha un nucleo semplice ma robusto ed estendibile.
Si basa sul motore Werkzeug WSGI per gestire la parte di web service e sul motore di template
Jinja2 per la costruzione di pagine web, viene distribuito con licenza libera BSD.
Ogni aspetto del comportamento oltre allo strato base è delegato a moduli ed estensioni da
mantenersi separatamente e trattare come librerie, ad esempio non c’è uno strato di astrazione
per la base di dati, validazione dei formulari, o qualsiasi altra componente per fornire funzio-
nalità comuni per le quali esistono già librerie di terze parti. Questo garantisce di avere uno
strato solido e snello su cui poter costruire applicazioni che possono ti tipologie e complessità
molto diverse tra loro.
Flask si presta in questo modo sia per la costruzione di portali web che per applicazioni
RESTFUL.
I progetti in Flask, a seconda della complessità, possono essere articolati in Blueprint o anche
in maniera monolitica, il primo caso si presta per applicazioni complesse ed i Blueprint sono
un modo per contingentare dal punto di vista logico degli aspetti precisi quali ad esempio
l’insieme della logica e della presentazione delle autenticazioni. L’approccio monolitico si
presta per casi relativamente semplici in cui il numero di endpoint a cui il motore deve fornire
una logica non risulta elevato.
L’approccio base per consentire a Flask di costruire un endpoint e quindi di potersi mettere
in ascolto è tramite l’uso delle route, da usare sia come decorator sia come dichiarazioni
d’oggetto, il primo approccio è quello di più immediata lettura, as es:
from flask import Flask
app = Flask(__name__)
@app.route("/")
def hello():
return "Hello World!"
if __name__ == "__main__":
app.run()
Creando un file .py con questo listato si crea un endpoint Flask per cui lanciando l’applica-
zione e caricando con un browser web l’indirizzo http://localhost:5000/ si andrà ad
eseguire la funziona hello associata alla route "/", si visualizzerà quindi Hello World!.
Questo meccanismo esemplificato usato sia per l’approccio monolitico che per quello modu-
lare tramite Blueprint è stato la base per gestire la suddivisione del portale per le applicazioni
dimostrative.
Dal portale principale è stata creata una struttura HTML+CSS poi riportata in tutti i sotto-
portali per garantire un Look&Feel compatibile con le linee guida, anche in questo caso ci si
è basati su Bootstrap per la gestione della responsività in base al dispositivo.
Attualmente la versione usata è:
• Flask
6/2021 17Deliverable 2.2 (PUBLIC) TDM - POR FESR 2014-2020/A1.2.2
URL: https://flask.palletsprojects.com/
Release: 1.0.4
4.2.1 HowTo
Oltre alle applicazioni demo descritte nelle prossime sezioni è stata creata una guida per aiu-
tare un possibile utente nella creazione di un servizio che possa andare ad interrogare i servizi
esposti dal portale DATA, gli esempi indicati non si discostano molto dalle routine realmente
usate nel portale DEMO.
La guida è pensata sia per utenti Python che per utenti PHP.
Il link per accedere alla pagina della guida è legata alla fine della pagina delle de-
mo: http://demo.tdm-project.it/demo/ o anche raggiungibili direttamente tramite i seguenti
indirizzi:
• Notebook Python
• Notebook PHP
4.3 Applicazioni demo
Il portale DEMO è sia contenitore di applicazio-
ni dimostrative che demo in se, infatti la prima
applicazione riguarda la visualizzazione di alcu-
ni eventi metereologici estremi sia per intensità di
precipitazione che come esclursione termica, i va-
lori vengono caricati automaticamente pescando i
dati dal portale DATA. Figura 4.5: Menu eventi
L’applicazione web costruita con Flask in questo
caso di occupa di creare la struttura della pagina, in particolare viene costruita l’intelaiatura
della pagina con i box indicati anche per il portale principale, nel box del contenuto viene
posizionato del testo descrittivo ed infine il risultato di un’interazione con lo strato di API di
CKAN, vengono quindi richieste due tipologie di dataset identificati coi tag heavy-rain e
heat-wave con la relativa collezione di dati. Per ogni collezione viene data la possibilità
di scaricare il dataset dal portale REST o caricare una visualizzazione caricando i dati da
DEMO.
Di seguito, forniamo, a titolo indicativo, un breve sunto delle principali applicazioni presen-
ti sul portale. L’insieme di applicazioni, e il comportamento di ogni applicazione, sono in
continuo aggiornamento, dato che il loro scopo è dimostrare i risultati ottenuti nel progetto.
6/2021 18Deliverable 2.2 (PUBLIC) TDM - POR FESR 2014-2020/A1.2.2
(a) Demo eventi (b) Dettaglio dati scaricabili da CKAN
4.3.1 Meteo e Radar
Concettualmente la struttura delle due demo è la stessa, tramite pulsanti viene presentata la
possibilità di scegliere la metodologia ed il giorno di interesse, alla pressione del pulsante
vengono richiamate le demo che puntano sui dati ospitati dal portale DATA.
Subito sotto i pulsanti viene mostrata la mappa interattiva rappresentante la demo in questione.
(a) Demo Meteo (b) Demo Radar
Le applicazioni dimostrative relative a meteo e radar si riferiscono alle attività descritte in
dettaglio nel Deliverable 3.2. Le due applicazioni, sviluppate nel quadro delle attività OR6,
sono inoltre descritte nei deliverable D6.1 e D6.2.
4.3.2 Fotovoltaico e Sensori Elettrici
L’applicazione demo Fotovoltaico fotovoltaico disegna diversi layer su una mappa leaflet, ogni
layer rappresenta una distribuzione di una tipologia di pannelli fotovoltaici nel territorio di
6/2021 19Deliverable 2.2 (PUBLIC) TDM - POR FESR 2014-2020/A1.2.2
Cagliari. Si tratta di una dimostrazione di come dati pubblici possono essere integrati nella
piattaforma.
I dati vengono caricati interrogando direttamente il portale DATA.
La pagina relativa ai sensori elettrici fornisce una descrizione dell’applicazione ed un rimando
al portale GRAFANA.
Figura 4.8: Demo Solare
Le applicazioni dimostrative relative a Fotovoltaico e Sensori Elettrici si riferiscono alle atti-
vità descritte in dettaglio nel Deliverable 3.2. Le due applicazioni, inoltre, sono strettamente
collegate alle attività sulla consapevolezza energetica svolte in OR5, le cui descrizioni sono
incluse nei deliverable D5.1 e D5.2.
4.3.3 Previsione consumi elettrici, generazione da impianto fotovoltaico,
piattaforma pianificazione RESS-BESS
4.3.3.1 Previsione consumi Elettrici
L’applicazione permette l’analisi e la previsione dei consumi elettrici di una abitazione. Il
calcolo si basa sui dati relativi ai consumi passati che può essere fornito tramite file in
formato CSV. Il file può provenire direttamente dalle letture ottenute dall’edge device, ma
l’applicazione permette di gestire anche file di altra provenienza. Vengono mostrate:
l’intera serie temporale della potenza misurata il grafico della stagionalità giornaliera, ovvero
i consumi medi calcolati per ogni ora della giornata il grafico della stagionalità settimanale,
ovvero i consumi medi calcolati per ogni giorno della settimana il grafico delle previsioni dei
consumi elettrici, calcolate per un periodo di 52 settimane future.
6/2021 20Deliverable 2.2 (PUBLIC) TDM - POR FESR 2014-2020/A1.2.2 Anche questa applicazione è strettamente collegata alle attività sulla consapevolezza energetica svolte in OR5, le cui descrizioni sono incluse nei deliverable D5.1 e D5.2. 4.3.3.2 Previsione generazione PV L’applicazione calcola il potenziale produttivo di un impianto fotovoltaico in base alle previsioni meteorologiche e alle caratteristiche dell’impianto stesso. L’utente dovrà immettere i parametri che caratterizzano l’impianto fotovoltaico e potrà ot- tenere i grafici relativi alle componenti di irraggiamento e la potenza erogata dall’impianto, sia tramite l’analisi dello storico degli ultimi 10 anni che come previsione della settimana successiva. Questa applicazione combina risultati provenienti da OR5, dedicato alla consapevolezza ener- getica, e OR4, per quanto riguarda la catena di previsioni meteo. Le descrizioni dei risultati di queste attività, e delle tecnologie alla base di questa applicazione, sono incluse nei deliverable D4.1, D4.2 per quanto riguarda gli aspetti meteo e D5.1 e D5.2 per quanto riguarda gli aspetti energetici. 4.3.3.3 Piattaforma pianificazione RES-BESS Strumento di pianificazione energetica che, sulla base delle risposte a poche semplici doman- de relative agli elementi che contribuiscono al consumo energetico in un edificio e l’eventuale presenza di RES (Renewable Energy Sources), fornisce delle raccomandazioni sulle possi- bili opzioni di dimensionamento di un sistema RES-BESS ottimale (Battery Energy Storage Systems). Questa applicaziona dimostrativa si riferiscono alle attività descritte in dettaglio nel Deliverable 5.1. 4.3.4 Previsione BOLAM Attraverso questa demo, alcune grandezze prodotte dalla previsione bigiornaliera, descritta nel rapporto tecnico Deliverable 4.1 del progetto TDM, vengono rese disponibili per la città metropolitana di Cagliari in un applicazione web destinata ad un utente/cittadino generico. In particolare è possibile visualizzare la pressione, la precipitazione. la nuvolosità, l’umidità e il vento nei due giorni successivi all’inizio della previsione. 6/2021 21
Deliverable 2.2 (PUBLIC) TDM - POR FESR 2014-2020/A1.2.2
Figura 4.9: Demo BOLAM
4.3.5 Confronto Temperature da sensori e da modelli
Questa demo, destinata ad un utente generico, permette di mettere a confronto per ciascun
sensore la temperatura misurata nelle ventiquattro ore precedenti e le previsioni della stessa
grandezza fornite da modelli di pubblico dominio sulla città metropolitana di Cagliari. I mo-
delli e le loro previsioni sono descritti nel rapporto tecnico 4.1 e 4.2 dell’obiettivo realizzativo
sicurezza del cittadino.
Figura 4.10: Demo Sensori vs Modelli
4.3.6 Monitoraggio Ambienti Indoor
Attraverso questa demo, viene dimostrato l’utilizzo dei sensori ambientali TDM per il monito-
raggio del microclima e del benessere termico all’interno di un ambiente. Questa applicazione
dimostrativa è un esempio di integrazione delle attività di progetto. L’applicazione è realiz-
zata nel quadro delle attività di OR6, mentre per il monitoraggio, vengono utilizzati i sensori
di OR3 e OR4 e gli edge realizzati in OR3, che vengono integrati nel sistema e diffusi come
open data attraverso la piattaforma di progetto realizzata in OR3. I dettagli sull’applicazione
sono presentati al deliverable D6.2.
6/2021 22Deliverable 2.2 (PUBLIC) TDM - POR FESR 2014-2020/A1.2.2
Figura 4.11: Demo Indoor
6/2021 235 GRAFANA
5.1 Descrizione
Come riportato anche nel Deliverable 3.2 Grafana è una piattaforma Web per la creazione di
pannelli di indicatori di vario tipo per la visualizzazione grafica di parametri e grafici basati su
serie storiche.
Grafana permette facilmente di rappresentare i dati provenienti dai sensori distribuiti attraver-
so heatmap, istogrammi, indicatori, grafici di vario tipo. È possibile definire visivamente le
regole di allarme per le metriche più importanti, queste vengono valutate continuamente ed
il sistema Grafana potrà, se necessario, inviare delle notifiche via e-mail o tramite Slack, Pa-
gerDuty, VictorOps, OpsGenie, o via webhook. Grafana vuole rappresentare una interfaccia
unificata per la visualizzazione di dati da diverse sorgenti, come Graphite, Influxdb, Prome-
theus, Elasticsearch, AWS CloudWatch ed altri. E’ altresı̀ possibile realizzare visualizzazioni
congiunte di dati provenienti da diverse sorgenti.
Il software è OpenSource ed è utilizzato, oltre che
per il portale dei dati, anche all’interno degli Edge
Gateway per la visualizzazione locale dei dati in
essi memorizzati. È inoltre possibile estendere i
moduli di visualizzazione offerti attualmente con
altri moduli dedicati, partendo dai moduli già pre-
senti in formato aperto e modificandoli per meglio
adeguarsi alle esigenze specifiche del progetto.
La sezione web Grafana del portale di progetto è
pensata per due scopi. Il primo è quello di fornire
ai visitatori un esempio delle possibilità di rappre-
sentazione dei dati raccolti attraverso i sensori. Il
secondo è quello di mostrare in maniera veloce
e intuitiva lo stato del progetto, il funzionamen-
to e la diffusione della rete di sensori e i dati da
questi raccolti in versione grafica (a differenza di
CKAN dai quali possono essere estratti anche in
forma tabellare). Figura 5.1: TDM Grafana
A regime gli indicatori presenti su CKAN mostre-
ranno dati sul funzionamento della rete di sensori
come:
• Numero di Edge Gateway attivi sul numero totale installato
• Numero di stazioni meteo sul totale installato
24Deliverable 2.2 (PUBLIC) TDM - POR FESR 2014-2020/A1.2.2
• Numero di stazioni di monitoraggio elettrico sul totale installato
• Disposizione come heatmap sul territorio
• Valori medi, massimi e medie dei parametri misurati sul territorio
• Serie temporali delle misurazioni aggregate di consumi elettrici in ambito domestico
• Serie temporali delle misurazioni aggregate dei consumi elettrici di edifici
• Serie temporali della generazione elettrica tramite sistemi PV
• Serie aggregate dei dati di consumo e di generazione elettrica da fotovoltaico
La visualizzazione in Grafana è basata sui concetti di Dashboard e di Panel. Il Panel è il
singolo strumento di rappresentazione dei dati, attraverso cruscotti, grafici, heatmap, o anche
tabella. La dashboard costituita da un insieme di panel e da una visione di insieme dei dati
analizzati. Sia le dashboard che i panels sono ampiamente configurabili dall’utente. Le dash-
board sono condivisibili, e permettono agli utenti di condividere una rappresentazione comune
dei dati.
A titolo di esempio, e suscettibile di sviluppi nel corso del progetto, nel portale è disponibile
una dashboard con la visualizzazione dei consumi energetici della sede del progetto TDM.
Si tratta di un impianto trifase che alimenta gli uffici con sia per il circuito di illuminazione,
per i computer e le altre apparecchiature elettroniche, per la computer room del progetto ed il
relativo impianto di raffrescamento. La dashboard si compone di:
• una sezione cruscotti, in cui è mostrato il valore più recente rilevato per ciascuna fase
dell’impianto, con una frequenza di campionamento di un minuto;
• una sezione con la potenza misurata per ciascuna delle linee nelle ultime ore,
rappresentata in forma di line plot;
• una sezione con i consumi elettrici giornalieri cumulati per le ultime 2 settimane di
misurazione;
• una sezione con un carpet plot della potenza delle tre linee per le ultime due settimane
di misurazione (si tratta di un istogramma 2D, il colore rappresenta la potenza media
nel quarto d’ora, l’asse x è diviso per giornate, l’asse y in funzione dell’ora del giorno);
• una sezione con la heat map dei consumi per le tre linee con bucket temporali pari ad un
quarto d’ora, che evidenzia la variabilità dei consumi;
• una sezione con la rilevazione dei profili medi di consumo giornaliero nell’ultima
settimana con risoluzione oraria.
Attualmente la versione usata e’:
• Grafana
URL: https://grafana.com/
Release: 5.3.4
6/2021 256 DATA e REST
Figura 6.1: portale DATA
DATA e REST sono i portali dedicati al dispacciamento dei dati, mentre DATA fornisce un
data source Open Data, REST è interrogabile tramite API e fornisce dati processati e relativi
descrittori.
Come riportato anche nel Deliverable 3.2 il sotto sistema di presentazione/distribuzione open-
data è il punto di accesso ai dati accumulate e generati dal progetto TDM. Esso è realizzato
attraverso una serie di diversi componenti integrati tra di loro, ognuno con caratteristiche e
compiti dedicati. Tra di essi i principali sono il portale CKAN, attraverso cui si forniscono,
principalmente, informazioni di indicizzazione sui dati disponibili e server di dati veri e propri
per cui è previsto un accesso secondo un protocollo di tipo REST. Di seguito descriviamo
CKAN e l’interfaccia REST prevista, La sezione 4 presenta dettagli sulle tipologie di dati
trattati, e le seguenti esempi su come utilizzare le interfacce e i dati.
6.1 Portale CKAN
La pubblicazione dei dati sotto forma di Open Data avviene tramite il portale web open
source CKAN (Comprehensive Knowledge Archive Network). CKAN è uno dei software
di riferimento per la pubblicazione di Open Data sia istituzionali, quali i dataset di Co-
muni e Regioni, sia governativi, sia privati, essendo largamente utilizzato anche da azien-
26Deliverable 2.2 (PUBLIC) TDM - POR FESR 2014-2020/A1.2.2
de che mettono a disposizione della propria utenza informazioni relative al funzionamento
dei servizi forniti e del lavoro svolto (trasporti, servizi al cittadino, utilities in generale).
La scelta di CKAN viene suggerita quindi sia dal
requisito di presentare ai cittadini una interfac-
cia di accesso e consultazione familiare e comu-
ne ad altri portali, sia dall’aderenza da parte del
progetto TDM alle best practice per le Smart Ci-
ties adottate dall’iniziativa Open and Agile Smart
Cities (OASC), alla quale il Comune di Cagliari,
territorio nel quale si svolge il progetto, ha aderito
sin dal 2015. Le API di CKAN, assieme alle API
FIWARE-NGSI, sono infatti suggerite da OASC Figura 6.2: Dettaglio risorsa
per l’implementazione della piattaforma di pub-
blicazione dei dati condivisi tra le Smart Cities
dell’iniziativa.
Il portale CKAN è strutturato in diverse componenti integrate tra loro:
• Il backend (Python), che gestisce la parte grafica, l’integrazione tra le varie componenti,
l’autenticazione e la pubblicazione delle API;
• il database (PostgreSQL), che contiene i metadati, i riferimenti e i dataset pubblicati
(ove presenti);
• il motore di ricerca (Apache Solr), che provvede a interrogare il database in ba-
se ai dataset richiesti dall’utente, sia attraverso identificativi predefiniti (tag, gruppi,
organizzazioni) sia attraverso ricerche full-text.
In particolare, il portale CKAN del progetto TDM è usato per indicizzare i dati raccolti e pro-
dotti dal progetto TDM. Gran parte di questi non risiedono su CKAN stesso, essendo acces-
sibili attraverso il portale REST specializzato nel fornire grossi moli di dati. CKAN contiene
quindi i link a tali dati, raggruppati per dataset o eventi (nel caso dei dati delle simulazioni
e radar meteorologici) corredati di informazioni (metadati) utili al loro recupero e utilizzo, e
permette di effettuare ricerche sul catalogo dei dataset da interfaccia web o tramite API.
I dataset attualmente presenti sono relativi a:
• eventi meteo significativi - ciascun dataset contiene sia sequenze di immagini raccolte
dal radar meteorologico che i risultati di simulazioni meteo dell’evento;
• sequenze di dati provenienti da sensori meteorologico/ambientali aggregati per ora e per
ultimi 10 minuti;
• sequenze di dati energetico/elettrici aggregati per ora e per ultimi 10 minuti;
• sequenze di dati relativi al monitoring del funzionamento dei dispositivi Edge Gateway
aggregati per ora e per ultimi 10 minuti.
Attualmente la versione usata è:
• CKAN
6/2021 27Deliverable 2.2 (PUBLIC) TDM - POR FESR 2014-2020/A1.2.2
URL: https://ckan.org/
Release: 2.8.1
6.2 Accesso ai dati
In generale, ogni dataset pubblicato da TDM può essere scaricato direttamente, una volta indi-
viduato attraverso il portale CKAN, per la creazione di una copia locale a scopo di elaborazioni
personalizzate. Mentre le sequenze di dati provenienti dalle misure di sensori sono, tipicamen-
te, di piccole dimensioni e possono essere scaricati agevolmente, nel caso dei dataset di tipo
volumetrico, come i risultati delle simulazioni meteo o le sequenze di acquisizione del radar
meteorologico, il volume di dati da spostare è notevolmente superiore e, spesso, l’interesse
è limitato solo ad una piccola parte dei dati prodotti. Ad esempio, a fini di visualizzazione
in un’applicazione esterna a TDM, può essere interessante accedere esclusivamente alle pre-
visioni sulla pioggia in un data regione spaziale e un dato intervallo temporale senza doversi
scaricare gigabytes di informazioni relativi a tutti gli altri campi prodotti dalla simulazione ma
non rilevanti ai propri scopi.
Per poter supportare in maniera efficiente questa modalità di accesso ai dati abbiamo definito
un protocollo REST che permetta, in maniera sistematica, un accesso casuale alle risorse,
questo compito è svolto dal portale REST.
Questo protocollo prevede che, una volta ottenuto l’identificativo della risorsa richiesta attra-
verso una query a CKAN, si possano accedere ai dati attraverso la costruzione di URI specifici
a struttura gerarchica. Ad esempio, con l’URI seguente
https://rest.tdm-project.it/tdm/odata/meteosim/moloch/
2018101702//description.json
si ha accesso ad una descrizione del dataset che può essere direttamente utilizzata dall’appli-
cazione client per stabilire quali siano i campi disponibili, la regione spaziale e temporale in
cui essi sono definiti e le relative risoluzioni.
Con indichiamo lo uuid che identifica la specifica istanza della simulazione.
La descrizione del dataset è sotto forma di un dato JSON con la seguente struttura:
{
"description": {
"group": "meteosim",
"class": "moloch",
"name": "2018101702",
"uid": "61324998-ae0f-4a35-a966-0d7dab6ee512",
"path": ,
"history": [
"Extracted by tdm_map_to_tree (V0.1)"
],
"start_time": "2018-10-17_02:00:00",
"end_time": "2018-10-19_00:00:00",
6/2021 28Deliverable 2.2 (PUBLIC) TDM - POR FESR 2014-2020/A1.2.2
"lon_range": "4.5:512:0.0226",
"lat_range": "36.0:512:0.0226"
},
"result": {
"resources": [
{
"name": "tcov",
"description": "Total cloud coverage [percent]",
...
},
{
"name": "tprec",
"description": "Total precipitation [kg/mˆ2]",
...
}
...
Dalla consultazione di quest’ultima è possibile per un programma client di sapere quali sono
i campi disponibili e in che range. L’accesso al dati specifici viene poi fatto utilizzando URI
più dettagliati. Ad esempio, con i seguenti URI si accede invece direttamente al campo di
temperatura (scalare) a 2m dal suolo e di vento (componenti U e V della velocità del vento) a
10 metri dal suolo.
https://rest.tdm-project.it/mnt/tdm-dic/tdm/simulations/
tdm-tree/tdm/odata/product/meteosim/moloch/2018101702/
61324998-ae0f-4a35-a966-0d7dab6ee512-lonlat/2018-10-17_02:
00:00/4.5:512:0.0226_36.0:512:0.0226/temp2m.tif
Dove il primo selettore determina il timestamp richiesto (UTC) ed il secondo specifica la
regione richiesta in coordinate GPS come una griglia regolare lon lat con i range definiti da
::.
6/2021 297 Conclusioni
In questo rapporto è stato presentato lo stato di avanzamento delle attività legate ai portali ed
ha due obiettivi principali: da un lato mostrare come sia articolato l’ecosistema dei portali
e le relazioni tra loro con particolare enfasi sul portale principale di progetto e quello legato
alla demo, dall’altro fornire un approfondimento e chiarimento su dove si possano i materiali
prodotti dal progetto.
All’interno di questo rapporto è stato presentato il portale di progetto principale, il portale
degli Open Data che insieme al portale dei dati processati fornisce il data source da interrogare
e da cui attingere, il portale visualizzatore di dati realtime per della sensoristica, il portale
dimostrativo che racchiude diversi esempio di come si possa andare ad usare i dati generati e
conservati declinando l’ambito applicativo al dominio di contesto.
Il portale principale fornisce un cappello sopra l’ecosistema di portali ed interfacce fornendo
i riferimenti tutto il materiale informativo ed approfondimenti nei domini specifici del pro-
getto, una finestra disseminativa sugli aspetti scientifici e riferimenti verso le applicazioni
dimostrative.
Al momento della scrittura le applicazioni web sono tutte residenti sull’infrastruttura interna
del sistema TDM tranne una per esigenze legate esclusivamente allo sviluppo e probabilmente
verrà portata sui server TDM successivamente. Tutte le applicazioni sono comunque visibili
dal portale TDM, nessuna esclusa.
Lo sviluppo dei portali e l’integrazione dei contenuti, sia quelli divulgativi ed informativi sia
di quelli applicativi finora ha seguito l’evoluzione del progetto fornendo al contempo una base
di verifica per la validazione delle applicazioni e dei dati, pertanto non sono stati evidenziati
particolari ritardi.
Trattandosi di un sistema in fase di continuo sviluppo e integrazione le informazioni qui
presentate potrebbero essere soggette a variazioni in futuro, ovviamente la struttura portan-
te sarà mantenuta in modo da preservare i riferimenti dati. Successivi aggiornamenti alla
documentazione saranno messi a disposizione attraverso il portale del progetto.
30Puoi anche leggere
