Quaderno IORoma III-2015

terrasi_eTypewriterPer ulteriori numeri, articoli, contatti:http://rivista.ording.roma.it

GLI EDITORIALI

Il saluto del Presidente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5di Carla Cappiello

LEditoriale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7di Francesco Marinuzzi

GLI ARTICOLI

Introduzione alla virtualizzazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8M. DEttorre

INSPIRE: una descrizione operativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18C. Iannucci

Gli strumenti della finanza immobiliare SGR, fondi immobiliari

e SIIQ come opportunit di sviluppo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36C. Pancheri

BIOFUEL Stato dellArte e Prospettive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44E. N. DAddario

GLI APPROFONDIMENTI

Scienza, tecnica e applicazioni dei moderni satelliti articiali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58C. Di Leo

Ruoli e responsabilit nellambito dei contratti di noleggio attrezzature:

il diverso regime di tutela nei casi di nolo a freddo e di nolo a caldo . . . . . . . . . . . . . . . . . . . . . . . . . . . 70L. C. Chiarenza, M. Cerri

Smart and traditional technologies in comparison: a multi-criteria model for evaluation

of energetic and economic efciency of buildings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80D. Morea, D. Campisi, S. Gitto, E. Farinelli, M. DAlessandris

DALLEVENTO

La valutazione del rischio vibrazione ed i suoi aspetti applicativi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94L. C. Chiarenza

LAREA WEB DEL QUADERNO E DELLA RIVISTA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .128

N. 3/2015

Sommario

Studio ABDR - Nuovo auditorium (Firenze) Copyright Moreno Maggi

Direttore responsabileStefano Giovenali

Direttore editorialeFrancesco Marinuzzi

Comitato di redazione

Sezione ACarla Cappiello Manuel Casalboni

Filippo Cascone Lucia Coticoni

Alessandro Caffarelli Giuseppe Carluccio

Carlo Fascinelli Francesco Fulvi

Gioacchino Giomi Maurizio Lucchini

Lorenzo Quaresima Tullio Russo

Sezione BGiorgio Mancurti

Amministrazione e redazionePiazza della Repubblica, 59 - 00185 Roma

Tel. 06 4879311 - Fax 06 487931223

Direzione artistica e Progetto graficoTiziana Primavera

StampaPress Up

Ordine degli Ingegneri della Provincia di RomaPiazza della Repubblica, 59 - 00185 Roma

www.ording.roma.it

[email protected]

Finito di stampare: dicembre 2015

Il Quaderno IOROMA un allegato alla rivista IOROMA

La Direzione rende noto che i contenuti, i pareri e le opinioni espresse negli articoli pubblicati rappresentano lesclusivo pensiero

degli autori, senza per questo aderire ad esse.

La Direzione declina ogni qualsiasi responsabilit derivante dalle affermazioni o dai contenuti forniti dagli autori, presenti nei suddetti

articoli.

Quaderno

Lingegneria del futuro

Negli ultimi dieci anni stiamo assistendo a dei forti cambiamenti, che vanno dalla crisi economicaalla modica degli equilibri politici mondiali allestrema globalizzazione. Questi elementi inuenzanoanche il mondo del lavoro e naturalmente i professionisti. Quindi dobbligo chiedersi cosa diven-ter lingegneria in un prossimo futuro.Sicuramente, come riportato da una ricerca del Centro Studi CNI di qualche tempo fa, vi sar pispazio per lingegneria che oggi chiamiamo del terzo settore, quella digital. Infatti, lespansionedellintelligenza articiale, porter grandi sviluppi in ambiti quali la domotica, la medicina, la messain sicurezza del territorio e lo sviluppo delle smart city, le citt intelligenti. Questo signica chegli ingegneri dovranno aprirsi ad ambiti disciplinari diversi, confrontandosi con altre professionalit.A mio avviso, si dovranno sempre pi sviluppare sinergie e collaborazioni, che si tradurranno inun cambiamento dellassetto economico classico dello studio o dellazienda ingegneristica. Sicreeranno degli studi associati con altri professionisti. Molto probabilmente si assister a un calodel ruolo dellingegneria civile, poich, soprattutto in occidente, diminuiranno gli investimenti, pub-blici e privati, per le costruzioni. Al contrario, nei Paesi arabi o in alcune zone dellAfrica, ledilizia,come sta gi avvenendo, sar incentivata. Certamente, nel settore edile il mercato, tuttavia, siorienter decisamente verso la costruzione di edici di qualit (Classe A e Classe B), compen-sando in tal modo i minori volumi dati dalla recessione del mercato immobiliare. Allinterno deinuovi progetti del settore delle costruzioni, la Classe A delle abitazioni e il comfort degli utenti ri-sulteranno sempre di pi abbinati, allo scopo di facilitare la vendibilit. Il cambiamento del mododi progettare nel campo dellingegneria civile sar quindi orientato da un lato alla sostenibilit am-bientale e allefcienza energetica, e dallaltro allesigenza di comfort e buona architettura. In una societ che tende allinvecchiamento come quella europea, lingegnere dovr porgere mag-giore attenzione al mondo della sanit e del sociale, sia per ci che concerne lingegneria gestio-nale sia lo sviluppo di nuove tecnologie. Si delineeranno nuovi proli nei settori della sicurezzaambientale e della green economy (risparmio energetico, energie rinnovabili etc). Sebbene ad oggi linvestimento nella sicurezza di un software per un oggetto collegato alla rete inferiore allinvestimento che fa una grande azienda per scrivere il sistema operativo di unosmartphone, nel futuro ci dovr essere maggiore sicurezza informatica, soprattutto per arginare ilcyber crime. Reti e dati, a causa della grande quantit di informazioni, anche di carattere perso-nale, che trasmettono, dovranno essere resi pi sicuri. Il settore della sicurezza informatica ca-ratterizzata da componenti economiche e tecnologiche che rappresentano fattori importanti perla competitivit europea. Il superamento della frammentazione del mercato attraverso la progres-siva creazione di un unico e reale ambito di sicurezza informatica europea consentirebbe di pro-muovere linnovazione e limitare la duplicazione dei programmi e delle attivit di ricerca.A livello di contratti, cosa a cui gi si sta assistendo, i posti ssi diminuiranno ancor di pi. Cisar, o dovrebbe esserci, un mercato molto pi mobile dellattuale. Saremo tutti pi essibili emobili nello spazio extra europeo. A livello di retribuzione si assister a dei profondi cambiamenti, collegati a quelli della domanda.Gli ingegneri del futuro dovranno essere molto preparati e continuamente aggiornati, per esseresempre appetibili sul mercato del lavoro.

Carla CappielloPresidente Ordine degli Ingegneri della Provincia di Roma

Il saluto del PresidenteDott. Ing. Carla Cappiello

Il Social Engineering, la fiducia e il disvalore del digitale

La sicurezza come una catena la cui forza data dallanello pi debole. La progressiva e

sempre pi pervasiva digitalizzazione ha portato efcienza, aumentato la produttivit ma sta

mettendo sempre pi in luce le debolezze strutturali degli anelli legati allorganizzazione, al

comportamento e ai fattori umani.

LIngegneria sociale o Social Engineering infatti, da non confondere con lingegneria per ilsociale, verte proprio sullo studio dei comportamenti e sulla gestione del fattore umano, al

ne di carpire informazioni di valore digitali senza utilizzare particolari e sosticate tecniche

informatiche.

Tre nomi e tre terremoti di tre mondi sacri fondati sul bene prezioso della Fiducia: Snowden

e il mondo delle relazioni internazionali, Falciani e il mondo dei segreti bancari svizzeri, Vati-

leaks e il mondo del vaticano e delle opere religiose.

In tutti questi casi una o pi persone interne abusando del proprio ruolo, spesso marginale ecomunque non apicale, hanno violato segreti ed informazioni riservatissime, intaccando un

capitale reputazionale formatosi, spesso, in centinaia di anni di storia. In un caso perno lu-

tilizzo di un semplice PC in rete per stendere la relazione nale si tramutato in un imper-

donabile errore, in termini di riservatezza della stessa.

Come siamo arrivati a tutto ci? E perch non si fatta adeguata prevenzione e tutela di que-

sto capitale reputazionale vitale e fondante la nuova sharing economy?A proprio avviso, soprattutto nei livelli decisionali, non c ancora la percezione che il digitale

disvalore se a priori non vengono prima gestiti adeguatamente tutti gli aspetti di sicurezzasui sistemi e sulle persone.

I primi, ad esempio, con logiche di ridondanza, di tracciamento e di allerta, i secondi con

specico aggiornamento sulla gestione del fattore umano e con lassegnazione dei ruoli api-

cali e di responsabilit a soggetti non solo competenti, ma con una loro etica professionale.Tutti i colleghi. con particolare riguardo a quelli abilitati al settore della ingegneria dellinfor-

mazione, in linea con quanto previsto dal DPR 328/2001 e la circolare 194/CNI del 2013 con

un adeguato aggiornamento professionale, possono essere i candidati ideali. Soggetti tutti

potenziali attori di azioni ed imprese innovative e non semplici storyteller delle stesse. Finch comunque non si capir quanto esposto, il valore del digitale e dei processi di digita-

lizzazione rischier di crollare al suo solo crescere, facendo apparire anche gli investimenti e

le infrastrutture ICT piricercate ed affascinanti, sempre pi fragili castelli di sabbia.

Francesco MarinuzziDirettore Editoriale

LEditorialeIng. Francesco Marinuzzi Ph.D.

Studio ABDR Museo dei bronzi di Riace (Reggio Calabria) Copyright Moreno Maggi

Per introdurci nellaffascinante mondo della virtualizzazione, interessante ripercorrere alcunipassaggi fondamentali che linformatica ha avuto a partire dalla fine del secolo scorso. In partico-lare il fatto che il Personal Computer (Pc), nelle sue diverse forme, inizi a diffondersi allinternodella societ dando luogo a quel fenomeno noto come informatica distribuita, che permise achiunque, con un modesto investimento, di entrare nel mondo dellinformatica. Il successo com-merciale del Pc suscit subito nelle case costruttrici un interesse sempre maggiore ad aumentar-ne le sue capacit elaborative, generando in questo modo una accesa competizione tra i produt-tori di hardware, per realizzare componenti con prestazioni sempre migliori e conquistare nuovequote di mercato. Tale corsa riguard principalmente la produzione dei chip di silicio destinati asvolgere sia le funzioni di unit di processo (cPU) sia le funzioni di memoria RAM. Si produsse co-

Quaderno

ORDInE DEGlI InGEGnERI DEllA PROvIncIA DI ROMA

INTRODUZIONE ALLAVIRTUALIZZAZIONE

a cura diIng. M. DEttorre

commissione Informatica

visto da:Ing. G. DAgneseIng. P. Reale

s un imponente sforzo di ricerca e sviluppoper perfezionare i sistemi di produzione e risol-vere i problemi che davano luogo a difettositche danneggiavano irrimediabilmente i compo-nenti. In particolare, fu necessario installare leparti pi critiche delle catene produttive nellecosiddette camere pulite, dotate di sistemi dicondizionamento, filtraggio e ricircolo dellaria,dove si entra solo indossando sofisticate tuteantipolvere, perch anche un singolo granellodi polvere, che pu capitare nel processo di in-cisione del chip, pu creare una interruzionenel circuito. Il risultato di tutto questo fu unacrescita anno dopo anno del numero di transi-stor che fu possibile integrare nei chip. GordonMoore, cofondatore di Intel, che nel 1971 rea-lizz la prima cPU (il 4004) in un unico chip, inun articolo del 1965 su una rivista specializza-ta, formul una legge empirica secondo la qua-le il numero di componenti che potevano esse-re integrati in un unico chip, portando cos unvantaggio economico, sarebbe raddoppiatoapprossimativamente ogni due anni. corretta-mente, nel suo articolo Moore pose in luce ladinamica economica del processo di fabbrica-zione dei chip, cio che integrare pi compo-nenti per chip porta un vantaggio competitivofinch gli scarti dovuti al processo di fabbrica-zione rimangono al minimo; se si hanno troppiscarti non c pi la convenienza economicaad aumentare il numero di componenti integra-ti, e quindi occorre modificare il processo pro-duttivo.Tale crescita di componenti e quindi delle pre-stazioni ancora in atto, anche se non pisolo un miglioramento tecnologico ma si usanoarchitetture per il processo delle informazioni ditipo innovativo e tecnologie multicore (ogni co-re costituisce una unit di processo indipen-dente e sono tutti integrati su un unico chip).come esempio di questa evoluzione conside-riamo la famiglia di processori x86 che la pilongeva e quindi la pi rappresentativa. Il pro-cessore 8086 che stato il capostipite, natonel 1978, aveva 29.000 transistor, un processoproduttivo con risoluzione di 3 m, nella versio-ne pi evoluta raggiungeva una velocit di 0,75MIPS e poteva indirizzare 1 MByte di memoria.Il processore Pentium, del 1993, con una archi-tettura molto pi complessa (denominata superscalare), ma volutamente mantenuta compati-bile con le versioni precedenti, per garantire laportabilit del software, possedeva 3,1 milionidi transistor ad 800 nm, raggiungeva una velo-cit di 100 MIPS e poteva indirizzare una me-moria di 4 GByte. nel 2012 sono stati presenta-ti i primi processori con oltre 2 miliardi di transi-stor a 22 nm e funzionanti a quasi 4 GHz (figu-ra 1).

roma


9

lindustria del software dal canto suo non stata a guardare e si sviluppata realizzandoprogrammi che fossero sempre pi semplici dautilizzare, sacrificando in pratica una parte del-la velocit di elaborazione messa a disposizio-ne dalle nuove generazioni di Pc, per adattarela macchina al mondo umano piuttosto che vi-ceversa. Per esempio dai primi sistemi operati-vi nei quali i comandi erano delle stringhe di te-sto che avevano una sintassi ben precisa daimparare a memoria si passati alle attuali in-terfacce interattive a colori, nelle quali consemplici ed intuitivi movimenti del mouse tipopunta e clicca o trascina e rilascia un elemen-to, possibile impartire comandi analoghi aquelli testuali di un tempo. le applicazioni han-no acquisito men sensibili al contesto e lapossibilit di rendere gli elementi visualizzatisempre pi simili al vero. la maggiore sempli-cit di uso ha contribuito ad una ancora mag-giore diffusione del Pc, che con le applicazionidi Office automation come gli elaboratori ditesti (Word) e fogli di calcolo (Excel), entratodi diritto in tutti gli uffici come strumento di la-voro. le reti di trasmissione dati subirono anche es-se un processo di perfezionamento, proprio acausa del desiderio di condividere le informa-zioni tra tutti i milioni di possessori di Pc. Furo-no creati dei programmi che, mediante dei pro-tocolli prestabiliti, consentivano di accedere re-motamente ad altri computer, per ottenere deiservizi di carattere informatico. Primo fra tutti laposta elettronica, poi laccesso alle banche da-ti e alle bacheche elettroniche o BBS, che era-no le antesignane dei social network attuali,

Figura 1:Transistor integeratoper microprocessore1971-1972vs regola di Moore.

roma


10

perch consentivano lo scambio di file e formedi messaggistica. nel 1993 il cERn rese dispo-nibile pubblicamente una tecnologia, inventatada Tim Berners lee, per semplificare laccessoalla vasta mole di documenti scientifici archi-viati nei propri computer. Era possibile prende-re un file di testo e renderlo interattivo, aggiun-gendo dei collegamenti (link) ad altri file neipunti di interesse. I file venivano richiamati au-tomaticamente se si attivava il collegamentostesso. Un file di testo cos modificato si defini-sce un ipertesto e la sua consultazione puavvenire in maniera non convenzionale, pas-sando ad altri testi, suoni, immagini, filmati,ecc. nacque cos il World Wide Web con lasua capacit di navigare in rete attraverso ilink ipertestuali. considerando la grande diffu-sione che aveva il Pc e lattrattiva per il nuovoservizio, che si configurava come un ambientemultimediale globale, facilmente accessibile eutilizzabile anche da non specialisti, gli svilup-patori subito crearono dei programmi per Pc(web browser) che consentivano di navigarenel web e quindi si ebbe una crescita espo-nenziale sia delle persone collegate in rete siadei siti ai quali accedere per navigare. le ap-plicazioni appena descritte aderiscono al mo-dello client-server, in cui un computer denomi-nato client invia richieste di servizio (es. aper-tura di una pagina web, visualizzazione delle e-mail ricevute, ecc.) ad un computer server chele elabora e invia i risultati al client che li visua-lizza. Il client ha il compito di interagire con lu-tente, quindi principalmente una interfacciagrafica evoluta per immettere le informazioni evisualizzare i risultati, che possono essere te-stuali piuttosto che grafiche, immagini o altro. Il

client pu essere un programma che gira sulPc, oppure su smartphone, oppure su sistemisimili a quelli che erano i terminali di accessoal mainframe (Thin client). Il server ha invece il compito di elaborare i ser-vizi richiesti dai client e quindi deve essere unsistema con risorse computazionali adeguateai servizi richiesti, anche tenendo conto del fat-to che deve far fronte a numerosi client con-temporaneamente generando le risposte in untempo accettabile. Il server non necessita di in-terfacce grafiche particolari, solo del minimonecessario per effettuare la sua gestione eduna volta attivato non richiede la presenza dipersonale. Ogni sito Internet ha dietro di seuno o pi server in funzione del numero di ser-vizi disponibili nel sito, della loro complessit eanche in funzione del numero di accessi con-temporanei da parte dei client che si intendegestire, perch le richieste dei client possonoessere smistate allinterno del sito su server di-versi in funzione del carico presente su ognunodi essi. Oltre alle applicazioni per i siti Internet,altre applicazioni di interesse aziendale sonostate realizzate secondo il modello client-ser-ver, soprattutto quelle che trattano grandiquantit di dati e vengono utilizzate da moltepersone contemporaneamente, come peresempio la gestione del personale, la contabi-lit aziendale, il ciclo attivo e passivo, la gestio-ne del magazzino, ecc. Si ottiene in tal modouna grande economia di scala, poich si con-centra la capacit elaborativa e la memoria dimassa su pochi sistemi server dimensionatiadeguatamente, mentre i client sono tipica-mente dei programmi che girano sui Pc dellepostazioni del personale che comunque devo-no esistere. In un sistema client-server inoltre facile mantenere i dati allineati ed aggiornatiper tutto il personale perch la fonte unica.Anche le procedure di salvataggio dei dati so-no semplificate perch basta considerare solodati conservati nei server (figura 2). I server devono essere attivi h24 per 365gg,ogni mancanza di funzionamento genera dis-servizi verso gli utenti che possono produrreanche dei danni economici consistenti (si pensialle aziende di e-commerce in Internet, checon il sito bloccato non possono ricevere le ri-chieste di acquisto da parte degli internauti).Per garantire un funzionamento senza interru-zioni, i server necessitano di alimentazioneelettrica di qualit ed in continuit assoluta, diraffreddamento dellaria per dissipare il caloregenerato e di una rete di trasmissione dati alta-mente affidabile (una interruzione del collega-mento in rete del server genera la stessa inter-ruzione di funzionamento). I centri di Elabora-zione Dati o Data Center sono progettati e rea-lizzati per soddisfare questi requisiti. Per mas-

Figura 2:Configurazione tipica

di un Data Centeraziendale

roma

11

progettazione di Data Center esiste una vastaletteratura tecnica (un bellissimo articolo sta-to pubblicato sul numero 4/2014 di questastessa rivista).Oltre ai guasti hardware e malfunzionamentidegli impianti per cui si cerca di sopperire conla ridondanza, ci sono i problemi legati alsoftware che spesso sono pi problematici esubdoli dei guasti hardware, si considerino peresempio: errori di sviluppo dei programmi, in-compatibilit tra programmi che funzionanocontemporaneamente sullo stesso server, at-tacchi informatici. Altri problemi sono legati aderrori di gestione, come per esempio apportaremodifiche non verificate alla configurazione deiserver, mancare di aggiornare i programmi co-me indicato dai produttori, ecc. In questi casi sitende a dedicare un server per ogni servizio, inmodo che in caso di problemi legati al softwa-re, questi rimangono confinati al server ed alsuo servizio associato senza compromettere al-tri servizi. Questa soluzione valida anche percontenere gli effetti degli errori di gestione, poi-ch un errore effettuato su un server non si ri-percuote sugli altri. Purtroppo per la conseguenza di utilizzareserver dedicati che poi ognuno di essi risultaampiamente sottoutilizzato. Si consideri infattiche i server attuali sono il frutto di cinquantan-ni di crescita continua delle prestazioni (leggedi Moore). I server di tipo x86 per esempio, chegrazie alla diffusione di Windows e la nascita diLinux come sistema operativo open source so-no diventati standard de facto nelle applicazio-ni client-server, sono utilizzati tipicamente al 10-15% della capacit complessiva. conside-rando questa situazione, i produttori di softwa-

simizzare laffidabilit, oltre ad utilizzare com-ponenti di alto livello qualitativo si tende a ri-dondare gli apparati o gli impianti consideraticritici. In tal modo lapparato o limpianto ridon-dato pu sopperire allapparato che si gua-stato e quindi il funzionamento complessivonon ne risente. la ridondanza diventata or-mai un elemento fondamentale di progetto, apartire dai server stessi, dove troviamo ridon-dati gli alimentatori, le ventole per la circolazio-ne dellaria, gli hard disk di storage per memo-rizzare i programmi ed i dati, che sono gestitidal software in modo che i dati vengono scrittisu pi hard disk contemporaneamente (cosid-dette configurazioni RAID), in modo tale che seuno si guasta ci sono gli altri che conservano idati. Anche tutta linfrastruttura di rete lAn vie-ne ridondata a partire dalle schede di trasmis-sione dati (Network Interface Card nIc) e tut-to il cablaggio di rete; a questo scopo vengonoutilizzati sistemi noti come NIC Teaming oLink aggregation secondo lo standard IEEE802.1aq, con i quali pi nIc su un unico servervengono aggregate a formare un unico colle-gamento logico, per avere ridondanza in casodi guasto di una di esse e per aumentare la ve-locit di trasmissione dati, visto che la velocitdel collegamento logico la velocit aggrega-ta dei collegamenti fisici.Per i Data Center sono state definite quattroclassi di affidabilit (Tier 1-4) che dipendonosostanzialmente dalle ridondanze che si consi-derano (Tabella 1).Ovviamente la scelta della classe di Tier darealizzare richiede unanalisi preventiva dei co-sti e benefici associati ad ognuna di esse. Aquesto scopo si consideri che nellambito della

Tabella 1 - Caratteristiche essenziali dei livelli di TIER

Classificazione TIER I TIER II TIER III TIER IV

livello diaffidabilit

99,671% 99,749% 99,982% 99,995%

Periodo di nonfunzionamento(downtime)

28,8 anno 22 ore anno 1,6 ore anno 2,4 min anno

Alimentazione 1 linea dialimentazione.

1 linea dialimentazione.

2 dorsaliindipendenti di

alimentazione, unaattiva e una in

stand-by

2 dorsaliindipendenti dialimentazione

entrambe attive

Ridondanzacomponentialimentazioneclimatizzazione

nessunaridondanza

Ridondanza n+1(un elemento in

pi)

Ridondanza n+1(un elemento inpi su una linea)

Ridondanza 2n(elementi su

entrambe le linee)

Possibilit dimanutenzioneconcorrente

no no Si Si


12

re hanno visto la possibilit di introdurre, con ri-sultati positivi, la tecnologia della virtualizzazio-ne nel mondo x86. Questa tecnologia consentedi eseguire pi sistemi operativi, indipendentitra loro, su un unico computer fisico, allocandoad ogni sistema operativo una porzione dellerisorse fisiche disponibili (cPU, memoria, harddisk, nIc). Per ottenere questo risultato ne-cessario utilizzare una tipologia di programmi,indicati in letteratura come hypervisor (chia-mati anche Virtual Machine Monitor o VMM),che si occupano di gestire laccesso alle risor-se fisiche da parte dei differenti sistemi operati-vi. lhypervisor genera degli ambienti software,totalmente isolati tra loro, dotati di proprie cPU,memoria RAM, disco rigido e nIc virtuali, cionon legate al vero hardware del server, entro iquali sono eseguiti i sistemi operativi e applica-zioni. Gli ambienti software sono chiamati mac-chine virtuali o VM e un sistema operativo inesecuzione su una VM chiamato guest OS. Ilcomputer fisico che ospita le VM chiamatohost computer. le nIc virtuali sono collegatetra loro attraverso uno switch di rete virtualeche si comporta come il suo equivalente fisico,quindi possono scambiare dati tra loro diretta-mente, senza necessit di accesso alla retedati fisica.Essendo del tutto indipendenti ed isolate tra lo-ro, ogni VM pu avere un sistema operativo eapplicativi diversi. Per esempio possono esser-ci Web Server, File Server, Mail Server e DBServer come VM su un unico Host (ovviamentese le esigenze prestazionali sono modeste) (fi-gura 3).Senza addentrarsi nei dettagli tecnici possiamoaffermare che la virtualizzazione pu avvenire

sostanzialmente in due modi: in full virtualiza-tion o in paravirtualization. nel primo casolhypervisor virtualizza completamente la cPU,sostituendo in tempo reale le istruzioni che nonpossono essere virtualizzate con nuove se-quenze mirate ad ottenere lo stesso effetto sen-za intervenire sullesecuzione di tutte le altreistruzioni sicure. In questo modo il guest OSnon in grado di distinguere la differenza conuna macchina fisica, n possono farlo le appli-cazioni che girano sopra di esso o altri compu-ter collegati in rete. nel secondo caso invecelhypervisor virtualizza la cPU per lesecuzionedelle istruzioni sicure, mentre per quelle nonvirtualizzabili si aspetta delle chiamate diretteda parte del guest OS. richiesto quindi, inquesto caso, un guest OS che sia stato adatta-to per poter funzionare correttamente. Sulle so-luzioni per la virtualizzazione, disponibile unavasta letteratura tecnica a cui rimandiamo pertutti gli approfondimenti del caso, perch ci in-teressa evidenziare nel seguito i benefici che sipossono ottenere adottando questa tecnologia.Prima di tutto grazie alla virtualizzazione pos-sibile consolidare i Data Center e le serverfarm, cio poter ridurre il numero di server fisi-ci, trasformando ognuno di essi in una VMequivalente; naturalmente alcuni server do-vranno esistere per svolgere le funzioni di ho-st delle VM, per il rapporto tra loro pu esse-re molto alto, anche decine di VM per server sele varie caratteristiche in gioco (potenza deiserver, complessit delle VM, ecc.) lo consen-tono.I server host in questo modo sono utilizzati al

80-90% della capacit complessiva, riducendoil gap di potenza elaborativa non utilizzata epermettendo di sfruttare al massimo le poten-zialit delle macchine a disposizione. Sono ri-dotti anche gli apparati di rete perch, come si detto le VM scambiano i dati tra loro attraver-so dei vSwitch. Ovviamente, con metodi tipoNIC teaming, deve essere garantita una ade-guata velocit di trasmissione dati in uscita dalcomputer host. Questo processo di consolida-mento pu quindi ridurre le esigenze di spazioe dei consumi di energia elettrica, utilizzata siaper lalimentazione dei server sia per il loro raf-freddamento, in maniera significativa. Da que-sto punto di vista, per coloro che perseguonola ricerca della sostenibilit ambientale la vir-tualizzazione diventa una scelta obbligata, per-ch attraverso di essa aumenta lefficienzaenergetica dei Data Center che diventano cossempre pi ecocompatibili (figura 4).Un altro fattore molto importante che con lu-so delle VM pu essere abbandonato il model-lo preesistente di corrispondenza univoca traapplicazioni e server (una sola applicazione in

roma

Figura 3:Configurazione di un

Host e VM che incorpo-ra un piccolo DataCenter Virtualizzato


roma

un server), perch ogni applicazione pu es-sere eseguita su una VM totalmente isolata dal-le altre, e questa condizione garantisce chequalunque problema dovuto al software in ese-cuzione su una VM non ha influenza sulle altre.Possono essere quindi fatti aggiornamenti sulsoftware che gira allinterno di una VM (guestOS e applicativi), oppure commessi errori digestione senza timori di compromettere il fun-zionamento di applicazioni attive su altre VM.la tecnologia della virtualizzazione genera poiun incremento della flessibilit operativa chenon ha eguali, si pensi per esempio a quando necessario creare nuovi servizi di tipo client-server, con pochi click del mouse si possonocreare le VM necessarie, si possono poi instal-lare i guest OS sulle VM ed i programmi appli-cativi, configurare le impostazioni della rete epoi il gioco fatto. lacquisto dei server fisici di-venta un evento eccezionale, riservato a quan-do il server host ha raggiunto il limite delle VMche pu ospitare con le prestazioni richieste,oppure nei casi particolari che richiedono co-munque dei server fisici. le VM a livello delserver fisico sono incapsulate in un insieme difile memorizzati sullo storage interno, quindi so-no semplici anche le operazioni di salvataggiodelle informazioni (backup), infatti basta fareuna copia dei file delle VM per salvare contem-poraneamente anche i guest OS, gli applicativie i dati che ci sono sopra, ma le VM si possono

anche eliminare facilmente cancellando i relativifile, come nel caso di una VM che non serve pioppure stata compromessa per esempio daun virus. Allo stesso modo una VM pu essereriattivata rapidamente utilizzando le copie dibackup al posto dei file cancellati. Si possonoanche creare delle VM preconfezionate con gliapplicativi pi usati, pronte da installare. nelle figure seguenti sono riportati dei graficiche dimostrano come sia recepita la validitdella virtualizzazione dagli addetti ai lavori delmondo IcT (Figure 5 e 6).la contropartita di questa flessibilit la ne-cessit di dover configurare e gestire lhypervi-sor, un compito non banale, che comunque siva sempre pi semplificando con levoluzionedel software spinta dalla grande richiesta dimercato. A questo punto viene per da chie-dersi cosa succede se si guasta il server host

Figura 4:Elementi di impatto perla riduzione deirequisiti energetici diun Data Center.Fonte: EnterpriseStrategy Group (ESG)

13

Figura 5:Impatto dellaVirtualizzazione suiData Center.Fonte: HP

roma


14

fisico che ospita le VM. Ovviamente non acca-de quello che sembra inevitabile, e cio chevanno fuori linea tutti i servizi client-server chehanno le relative VM attive sullhost che si guastato. Infatti stato messo a punto un siste-ma di salvaguardia, di cui parleremo ora, checonsente di mantenere le VM attive in caso diguasti hardware. Innanzitutto ricordiamo checostruttivamente un Data Center virtualizzato

contiene numerosi server host collegati in rete,ognuno dei quali ha in esecuzione su di se uncerto numero di VM. I file che incapsulano leVM sono memorizzati su uno storage condivisotra tutti gli host (questo possibile per esempiotramite la tecnologia della Storage AreaNetwork o SAN), e una VM pu essere attivatada uno qualunque degli host che accedono al-lo storage condiviso. Supponendo che un host

Figura 6:Opportunit di

utilizzare lavirtualizzazione.

Fonte:Enterprise Strategy

Group (ESG)

roma


15

Figura 7:Guasto di un Host

Figura 8:Sistemi migrati su altriHost

si guasti, le VM che erano attive su di essovengono migrate sugli altri Host che hanno ri-sorse disponibili, notificando ai nuovi Host i filesullo storage condiviso da considerare. nelledue figure seguenti sono esemplificate le situa-zioni prima e dopo il guasto. Il processo che consente alle VM di rimanereattive modificando in tempo reale lHost che leha in esecuzione stato automatizzato facen-

do in modo che gli Host si scambino tra lorocontinuamente le informazioni relative alle VMche ognuno di essi ha in carico e indicazionidel corretto funzionamento (heartbeat) tramiteuna rete di interconnessione dedicata.Questo processo pu essere avviato anchemanualmente in caso sia necessario il fermo diun Host per maintenance o upgrade hardware(Figure 7 e 8).

Host 3 in fault migrazione

delle sue VM sugli Host

pi scarichi

roma


16

Figura 10:Migrazione di una

VM e riduzionedella richiesta di

risorse fisiche

Figura 9:Host in sovraccarico

Host 3 in sovraccarico

migrazione di una VM per

riportare lequiliberio

roma


17

la migrazione di una VM da un Host allaltro puessere eseguita anche per bilanciare meglio ilcarico tra tutti gli Host, come esemplificato nel-le figure di pagina 16, dove si riscontra che suun Host la richiesta di risorse fisiche da partedelle VM eccessiva e le performance delle VMsu questo Host sono degradate. Di conseguen-za una di esse viene migrata su un altro Host piscarico. Gli hypervisor attuali consentono di ef-fettuare queste migrazioni in modo automatico esenza interruzione del servizio da parte delle VMche vengono migrate (Figura 9 e 10).Un ultimo aspetto che consideriamo la prero-gativa offerta dalla virtualizzazione, di semplifi-care la pianificazione delle nuove esigenze dicapacit elaborativa (capacity planning). Infattiin un Data Center virtualizzato si possono ap-provvigionare (provisioning) dei server Hosttutti uguali tra loro e poi tramite le VM si posso-no creare gli ambienti virtualizzati, che hannole risorse fisiche richieste dai sistemi operativie programmi applicativi. Ogni VM, infatti, creaun ambiente fisico che non legato al verohardware del server Host ed configurabile apiacere.le VM possono rimanere inalterate con i loroguest OS e applicativi anche nel caso di up-

grade dellhardware o approvvigionamento diserver appartenenti a nuove generazioni.Il processo di provisioning stato anche auto-matizzato stabilendo delle soglie di risorse di-sponibili al di sopra delle quali si attivano deglialert che necessario aggiungere nuove risor-se fisiche (ad esempio richiesta di nuovo spa-zio storage se quello disponibile si sta esau-rendo).In conclusione possiamo affermare che la tec-nologia della virtualizzazione per i sistemi x86introdotta a partire dal 1998 ormai una tecno-logia matura per essere utilizzata anche negliambienti IcT pi complessi e che richiedonoalte prestazioni, quali per esempio quelli chesvolgono servizi direttamente a contatto con gliutenti (e-commerce, home banking, e-govern-ment) i benefici che si possono ottenere in ter-mini di consolidamento delle risorse hardware,di risparmio energetico e di flessibilit operati-va consentono di avere un rapido ritorno del-linvestimento necessario. Inoltre luso delle VMconsente di avere una affidabilit superiore ri-spetto ai sistemi convenzionali basati solo sullaridondanza dellhardware, proprio per la capa-cit di poter migrare automaticamente le VMda un server allaltro.

ORdIne deGLI InGeGneRI deLLa pROvInCIa dI ROMa

INSPIRE: UNA DESCRIZIONE OPERATIVA

a cura di Ing. C. Iannucci

commissioneGeomatica

visto daIng. M. G. CrespiIng. R. Giannini

IntroduzioneLa geomatica definibile come un insieme ditecnologie di rilevamento e trattamento infor-matico dei dati relativi alla Terra e allambiente.Questo termine, nato alla fine degli anni ottan-ta, descrive il dominio interdisciplinare genera-to dallincontro dei tradizionali scopi e mezzidella geodesia alle diverse scale con le capa-cit di archiviazione, elaborazione e rappresen-tazione dei dati rese disponibili dalle tecnolo-gie dellinformazione e della comunicazione(ICT). Come conseguenza di questo incontro,da una parte sono stati rivoluzionati i preesi-stenti metodi di lavoro, ad esempio per il rilievo

e il disegno della cartografia e per la formazio-ne dei catasti; dallaltra parte, sono nate nuoveapplicazioni di largo impiego, come i satellitiper losservazione della Terra, i sistemi di posi-zionamento, gli strumenti di navigazione stra-dale. In questo contesto, si usa il termine di da-to spaziale o di dato georeferenziato per desi-gnare quegli elementi di informazione cui as-sociabile un riferimento di posizione geografi-ca, sia staticamente (ad sempio, lubicazionedi un edificio) sia dinamicamente (ad esempio,la traiettoria di un veicolo) (Gomarasca, 2009).La variet (inevitabile) di dati e di applicazioniha generato una variet (non necessaria) di so-

siglio del 14 marzo 2007, che ha istituito InSpI-Re (INfrastructure for SPatial InfoRmation inEurope). La direttiva InSpIRe e la sua trasposi-zione nel sistema normativo italiano (tramite ildecreto legislativo 27 gennaio 2010, n. 32, at-tuazione della direttiva 2007/2/Ce, che istitui-sce uninfrastruttura per linformazione territo-riale nella Comunit europea InSpIRe) costi-tuiscono la fonte di un nuovo quadro operativo,cui afferiscono norme giuridiche e tecnicheche hanno impatto sulla pratica professionaledegli esperti di geomatica, in termini sia di of-ferta che di domanda di servizi e di prodotti.proprio nella pratica professionale esperienzacomune lesistenza di due fenomeni apparente-mente contrastanti: ladesione spesso acriticaalle nuove norme da una parte e il rifiuto delleopportunit che queste stesse norme offrono. Sisono visti capitolati tecnici prescriventi il rispet-to di prescrizioni InSpIRe anche dove tali pre-scrizioni erano non previste o non ancora co-genti; dallaltra, i requisiti per il progetto e la ma-nutenzione di sistemi GIS continuano spesso aprescindere dalla compatibilit con le normeInSpIRe attuali o prevedibili, forse nellillusionedi poter rimandare tale compatibilit ad un futu-ro indeterminato. di fatto, entrambi i fenomeniappaiono essere sostanzialmente accomunatidalla stessa causa: una mancanza di una ade-guata informazione specifica.va detto che la relativa complessit dellargo-mento e linevitabile tendenza degli addetti ailavori ad una comunicazione autoreferenzialenon hanno condotto finora ad una generalizza-ta presa datto dellevoluzione sostanziale cheuna IdT (o SdI: Spatial Data Infrastructure) im-pone al mondo della geomatica, con riferimen-to allinteroperabilit e allarmonizzazione del-linformazione. Ci costituisce un problema nonpiccolo, specialmente in un momento in cui pa-radossalmente la geomatica affronta una im-portante crisi evolutiva: i dati georeferenziatisono praticamente ubiqui in tutti i campi del-lICT, ma gli strumenti applicativi (in particolare,le tradizionali piattaforme GIS) hanno raggiuntouna usabilit tale da spesso non necessitaredelle competenze specialistiche dei geomatici.In qualche modo, la geomatica sembra poteressere vittima del proprio successo.In conseguenza, appare utile dare una visionedi insieme di InSpIRe, che da un lato sia suffi-cientemente completa, ma dallaltro lato non ri-chieda necessariamente competenze speciali-stiche pregresse. Ci dovrebbe contribuire afar s che le opportunit siano correttamentecolte non solo dagli specialisti del settore, maanche da tutte le altre parti interessate: profes-sionisti, imprese, pubblica amministrazione, cit-tadini.

19


luzioni, principalmente in termini di strumenti dielaborazione e di formati dellinformazione, cheostacola la condivisione dei dati georeferenzia-ti. Ci ha condotto, similmente a quanto av-venuto per tutti i campi della tecnologia, allevi-denziarsi della necessit di ampie iniziative distandardizzazione, che sono state promosseprincipalmente ad opera dellOpen GeospatialConsortium (OGC) e del comitato tecnico TC21 dell International Organization for Standar-dization (ISO).nel tempo, al tradizionale concetto di sistemainformativo geografico (GIS - GeographicalInformation System) si affiancato fino a risul-tare prevalente il concetto di Infrastruttura diDati Territoriali (IdT). a questo proposito, va ri-levata in particolare ladozione della direttiva2007/2/Ce del parlamento europeo e del Con-


20

te telematica risulta conveniente spostare unaparte della logica applicativa sul sistema client,per non appesantire lelaborazione con i tempirichiesti dalla trasmissione bidirezionale digrandi volumi di dati. daltra parte, per elabora-zioni di limitata entit oppure per reti di ade-guata capacit (come ormai Internet, almenonelle sue versioni business), il sistema clientospita solo un browser, ottenendo cos il massi-mo della flessibilit: le evoluzioni funzionali del-la logica applicativa sono rese disponibili aiclient modificando solo il software residente sulserver applicativo.

Dal GIS alle SDIa fine degli anni novanta Burroughs e Mcdon-nell (1998) rilevavano gi un proliferare di defi-nizioni di un GIS, che di volta in volta ne mette-vano in evidenza i diversi aspetti (funzionali,operativi, organizzativi, ecc.). a volte in passa-to (ad es. in arnaud et al., 1993) con il termineGIS ci si riferiti sbrigativamente (ma non cor-rettamente) solo al software e allhardware,cio agli strumenti che automatizzano il tratta-mento dei dati e a cui in senso stretto si appli-ca il temine di sistema informatico. nel presente contesto, i sistemi GIS, breve-mente descritti pi sopra, sono a tutti gli effetticonsiderati nella loro essenza di sistemi infor-mativi. Come noto un sistema informativo for-mato dalle seguenti componenti: persone (tecnici, gestori, utenti); norme (leggi, accordi, finalit, usi, strutture

operative, piani strategici); Hardware (processori, memorie, reti, dispo-

sitivi di input e output); Software (interfacce utente, funzioni appli-

cative, strumenti di base e di ambiente).In realt, un sistema informativo (che quindi in-clude il sistema informatico) ha capacit di ero-gare servizi agli utenti finali solo se le variecomponenti sono bilanciate e armonizzate tradi loro: ci vale in particolare per quelle com-ponenti, come le persone e le norme, il cuioperare non totalmente riconducibile a logi-che esprimibili tramite algoritmi. Si pensi alluti-lizzo (ormai molto esteso) dellinformatica nellaprogettazione urbanistica: per quanto pervasivie potenti siano gli strumenti informatici adottati,le ipotesi di intervento e le decisioni di pianosono generati dalla professionalit delle perso-ne, non certo dal solo sistema informatico. da ci deriva la necessit di progettare la strut-tura di un GIS (principalmente in termini di datiarchiviati e funzioni disponibili) in accordo conlorganizzazione in cui il GIS stesso deve esse-re fruito. a parit di servizi offerti, si privilegiaun determinato sistema operativo oppure sisceglie un software FOSS tenendo conto di co-sa consentito dal contesto normativo e dalla

roma

I sistemi informativi geograficiI sistemi GIS sono nati dallevoluzione deglistrumenti di automazione del disegno della car-tografia. Questa evoluzione si basata sullapossibilit di disporre di strutture di dati alfanu-merici associate ai segni grafici della cartogra-fia in formato digitale. La capacit di inserire,aggiornare, interrogare e cancellare tali dati al-fanumerici ha evidenziato le potenzialit di uti-lizzo della rappresentazione cartografica comeinterfaccia di colloquio con i contenuti informa-tivi delle strutture dati cos create. Queste strutture dati sono evolute nel tempo fi-no a permettere larchiviazione congiunta deidati alfanumerici e degli elementi grafici, utiliz-zando principalmente strumenti software comei dBMS (Data Base Management System) intecnologia relazionale con estensioni spaziali.Conseguentemente, si sono evoluti anche i lin-guaggi di gestione ed interrogazione (in parti-colare: SQL - Structured Query Language), finoa consentire query di tipo topologico (ad esem-pio: estrarre la lista di tutti gli edifici costruitidopo il 1966 che si trovano a non pi di 200metri dalla riva di un dato fiume e che ricadonoin una zona protetta).per la realizzazione di un GIS, esistono moltesoluzioni software, sia proprietarie (cio a fron-te del pagamento di una licenza duso) sia libe-re. In questo secondo caso si parla di FOSS Free & Open Source Software; la relativa licen-za gratuita e permette di utilizzare, copiare,studiare, cambiare e migliorare il software il cuicodice sorgente sempre accessibile.al fine di salvaguardare la massima flessibilitrealizzativa, lapproccio pi generale separa ilsoftware applicativo (ad esempio, gli strumentidi interrogazione dati e di produzione di carto-grafie) dal software per la gestione della basedati (i dBMS con estensioni spaziali, citati pisopra). Conseguentemente, si potranno averesoluzioni in cui entrambi o solo uno dei softwa-re proprietario oppure FOSS.dal punto di vista architetturale, il modello piadottato quello basato su tre livelli distinti:client, logica applicativa, base dati. per motividi efficienza e di sicurezza, la base dati se-parata dalla logica applicativa e spesso resi-dente su server differenti; la logica applicativa,a sua volta, pu risiedere su server dedicati madi solito viene attivata tramite interfacce acces-sibili dai sistemi a disposizione dellutente fina-le (sistemi client). Il server della base dati, ilserver della logica applicativa e il sistemaclient sono connessi da una rete telematica, ditipo locale o geografico (dove, parlando di retitelematiche, il termine geografico si usa perdenotare reti di grande estensione ma non haattinenza allinformazione georeferenziata).In funzione della capacit di trasporto della re-

roma


21

siano in grado di colloquiare, in particolarequando queste organizzazioni appartengono astrutture di tipo federativo (che, come gli USa olUe, delegano molto alle componenti della fe-derazione). Questo comporta la necessit di concordare laforma e il significato dei dati, in modo tale dapermetterne luso congiunto da parte di sistemidiversi. Ci si esprime sinteticamente facendoricorso ai concetti di armonizzazione e di inte-roperabilit dei dati.In teoria, si potrebbe pensare di operare un pe-sante e costoso intervento di unificazione ditutti i sistemi informativi chiamati a collaborare.Questo intervento pu essere rivolto ad imporrela stessa soluzione realizzativa a tutte le orga-nizzazioni coinvolte, oppure a creare un ulterio-re sistema informativo, alimentato da tutti i si-

cultura professionale del gestore del sistema edellutenza dei servizi. Ci ha permesso certa-mente di creare sistemi efficienti, anche digrandi dimensioni; tuttavia, ha portato ancheverso lisolamento di questi sistemi nei confinidella rispettiva organizzazione: identici feno-meni territoriali (ad esempio, la presenza diaree naturali da proteggere) vengono descrittiin termini diversi a seconda dei confini (ammi-nistrativi, organizzativi, ecc.) entro cui ricado-no. poich gran parte dei fenomeni oggetto deiGIS sono per loro natura indipendenti da taliconfini, la loro gestione richiede molto spessolutilizzo congiunto di dati raccolti e archiviatida entit diverse sia per ambito territoriale siaper competenza disciplinare. da qui nasce lanecessit che GIS di organizzazioni diverse

roma


22

stemi preesistenti. Interventi di questo tipo han-no avuto ragione di esistere nel caso di conte-sti organizzativi molto centralizzati e gerarchici(ad es. il sistema del Ministero dellIstruzioneoppure il sistema della Ragioneria di Stato). Laddove le organizzazioni siano legate da vin-coli non tanto gerarchici, ma piuttosto di tipofederativo (si pensi ai sistemi di amministrazio-ni centrali che interfacciano correntemente gliomologhi sistemi delle singole Regioni), tale ti-po di intervento risulta fortemente problemati-co: questa affermazione pu essere conferma-ta anche ricordando le difficolt della inizialerealizzazione del SIna (il sistema informativodel Ministero dellambiente) alla fine degli anniottanta, prima che (realizzando il SInanet) sene modificasse radicalmente la struttura, sullabase anche del successo del modello architet-turale basato su rete che il sistema eIOneTdellEuropean Environment Agency (eea) ave-va adottato a livello dellintera Ue. nasce quindi una modalit diversa di vedere idati (quelli georeferenziati, ma non solo quelli),particolarmente adatta per quei contesti, chevedono molte organizzazioni produrre ed utiliz-zare linformazione dello stesso dominio disci-plinare: questo appunto il caso dellambiente,dove operano organizzazioni le cui competen-ze sono delimitate da confini amministrativi (es.le Regioni) oppure sono delegate gerarchica-mente (es. le province rispetto alle Regioni) op-pure afferiscono a domini trasversali (es. i ser-

vizi meteo, gli organi cartografici). In questamodalit, differenti sistemi informativi uniforma-no le reciproche interfacce, pur mantenendo(nei modi e nei tempi ritenuti convenienti) lapropria specificit interna. Questa modalitpermette di far cooperare organizzazioni di di-verse origini e tradizioni (cui spesso ci si riferi-sce mediante il termine inglese di legacy) sullabase di soluzioni operative condivisibili, senzadisperdere gli investimenti precedenti, in parti-colare per ci che riguarda il software elhardware.ai fini di questa cooperazione, la disponibilitdi una rete universale come Internet permettela connessione telematica di sistemi diversi sul-la base di protocolli software di larghissima ac-cettazione come la suite TCp/Ip; molte altre so-luzioni (che qui non possono essere adeguata-mente descritte) sono disponibili in termini disoftware di base e di ambiente. poichlhardware e il software non pongono limiti inprincipio insuperabili, a questo punto occorreagire principalmente sul componente norme(ma anche sul componente persone) per su-perare le barriere che impediscono luso con-giunto del patrimonio informativo posseduto neitanti GIS mono-organizzazione.Si sviluppato cos il concetto di SdI (SpatialData Infrastructure) o IdT (Infrastruttura di datiTerritoriali); come riferimento temporale vieneusualmente indicato lanno 1994, quando negliStati Uniti la National Spatial Data Infrastructure

roma


23

stata oggetto dellexecutive Order 12906 del-la presidenza Clinton (nSdI, 1994). In europa,dal 2002 stata promossa liniziativa InSpIRe(annoni et al. 2004), che ha generato poi lo-monima direttiva nel 2007. Come ovvio, ilconcetto di SdI si sviluppato nella realt at-traverso una molteplicit di esperienze e di ap-procci, cui corrispondono definizioni differentianche se riconducibili allo stesso comuneobiettivo. dessers (2012) riporta una trentina di varie de-finizioni per la SdI, che ruotano intorno ai com-ponenti di base e agli obiettivi di servizio. puessere di interesse confrontare la definizionedella nSdI come espressa dallexecutive Order(nSdI, 1994):

National Spatial Data Infrastructure (NSDI)means the technology, policies, standardsand human resources necessary to acqui-re, process, store, distribute, and improveutilization of geospatial data

con quella di InSpIRe (come riportato nel testodella direttiva):

infrastruttura per linformazione territoriale:i metadati, i set di dati territoriali e i servizirelativi ai dati territoriali; i servizi e le tecno-logie di rete; gli accordi in materia di condi-visione, accesso e utilizzo dei dati e i mec-canismi, i processi e le procedure di coor-dinamento e di monitoraggio stabilite, at-tuate o rese disponibili conformemente allapresente direttiva.

facile rilevare come la prima definizione sot-tolinei lo scopo (il miglioramento dellutilizzodellinformazione spaziale) mentre la secondadefinizione evidenzi i componenti ritenuti ne-cessari. va comunque notato che la definizioneesplicitata da InSpIRe segua nel testo della di-rettiva una estesa lista di premesse, che chiari-scono lo scopo perseguito e i risultati attesi;inoltre, larticolo 1 della direttiva sottolinea il ca-rattere federativo della SdI europea dichiaran-do specificamente che: INSPIRE si fonda sulle infrastrutture per linfor-mazione territoriale create e gestite dagli Statimembri.Lorganizzazione Global Spatial Data Infra-structure (www.gsdi.org) ha redatto un utilemanuale che costituisce il riferimento per chi siinteressa di SdI: il cosiddetto Cookbook (ne-bert, 2004). In questo manuale viene fornitauna definizione sufficientemente articolata, ingrado di cogliere tutti gli aspetti della tematica:

The term Spatial Data Infrastructure(SDI) is often used to denote the relevantbase collection of technologies, policiesand institutional arrangements that facilitatethe availability of and access to spatial da-ta. The SDI provides a basis for spatial data

discovery, evaluation, and application forusers and providers within all levels of gov-ernment, the commercial sector, the non-profit sector, academia, and by citizens ingeneral An SDI must be more than a sin-gle data set or database; an SDI hosts geo-graphic data and attributes, sufficient do-cumentation (metadata), a means to disco-ver, visualize, and evaluate the data (cata-logues and Web mapping), and somemethod to provide access to the geograph-ic data. Beyond this are additional servicesor software to support applications of thedata. To make an SDI functional, it must al-so include the organisational agreementsneeded to coordinate and administer it on alocal, regional, national, and or trans-na-tional scale.

Larmonizzazione e linteroperabilit dei datiper contestualizzare la rilevanza di InSpIRe, bene ritornare sulla finalit di uso congiunto delpatrimonio informativo posseduto nei tanti GISesistenti. Si visto pi sopra che questo usocongiunto sempre pi necessario e che, peraltro, i GIS preesistenti sono orientati al servizioognuno della propria organizzazione (perquanto vasta questa possa essere). Il proble-ma di base la molteplicit di enti che custodi-scono dati territoriali, da cui conseguono la di-versit di strutturazione di questi dati e, inevita-bilmente, gli ostacoli al reperimento, allacces-so e alluso congiunto dei dati stessi. pertan-to emersa la necessit di assicurare levoluzio-ne dal GIS alla SdI (Salvemini, 2004).Lo sviluppo di una SdI (come quella di InSpI-Re) si appoggia sui concetti correlati di intero-perabilit e di armonizzazione dei dati. per pro-cedere a inquadrare correttamente questi dueconcetti, si pu partire da un dato di fatto: il20% circa dei cittadini europei vivono entro 50Km da un confine di stato; lanalisi e la gestio-ne di fenomeni ambientali in queste aree richie-de necessariamente luso di dati prodotti suidue lati del confine. Se prendiamo in conside-razione anche i confini delle regioni di tipo fe-derale (con elevati livelli di autonomia organiz-zativa, come in austria, Belgio, Germania, Italiae Spagna), luso congiunto di dati transfronta-lieri interessa la maggior parte del territorio del-lUnione europea.nella concreta articolazione dellUnione euro-pea (che tra i suoi 28 Stati membri raccoglietradizioni tecniche e amministrative ben diver-se tra loro) inevitabile che i dati (e non soloquelli geoferenziati) siano prodotti con moltepli-ci metodi e strumenti, malgrado gli intensi pro-cessi di produzione di standard sia ex lege siade facto che da sempre accompagnano lo svi-

roma


24

luppo tecnico-economico. Ci comporta spes-so linsorgere di un rilevante problema: se sivogliono utilizzare insiemi di dati (data set, nellinguaggio di InSpIRe) provenienti da fonti di-verse, pu risultare che questi data set debba-no essere sottoposti a rielaborazioni anche so-stanziali o addirittura possano risultare incom-patibili tra di loro. La condizione ideale sarebbe quella in cui iprocessi e gli oggetti del mondo reale fosserodescritti omogeneamente in ogni settore con-cettuale, nel tempo e nello spazio: ovvio chein tal caso questo problema non si porrebbe.Quando ci si riferisce allarmonizzazione deidata set, si evidenziano due aspetti distinti macomplementari: i data set sono generati sulla base di sche-

mi dati (o di ontologie, dove disponibili) cheriuniscono entit, relazioni ed attributi inmodo tale da esplicitare il contenuto infor-mativo derivabile dai singoli dati;

i data set sono caratterizzati da metadati,cio da ulteriori dati che descrivono lorigi-ne, il significato, i metodi di produzione, lecondizioni di utilizzo del data set nel suo in-sieme e dei suoi componenti ai vari livelli distruttura.

Se le diverse organizzazioni concordasseronorme sullutilizzo sia di schemi dati identici oconsistenti (a seconda che si tratti dello stessotema o di temi affini) sia di metadati identici(come tipologia e come valore), larmonizzazio-ne dei data set sarebbe assicurata nativamen-te. Queste norme sono appunto lobiettivo diuna SdI come InSpIRe in europa. evidentemente, larmonizzazione completa deidata set un ideale punto di arrivo verso cuiconvergere, non il punto di partenza di unaSdI. nella realt operativa vanno presi in consi-derazione due fatti: luso congiunto di data set di diversa fonte

una necessit di oggi, la cui soluzionenon pu essere rimandata al futuro (nean-che nellipotesi che tale futuro possa essereragionevolmente prevedibile);

esiste una mole enorme di data set (di valo-re certamente elevatissimo) che sono statiraccolti in passato e che non possono es-sere dispersi (neanche nel caso di raggiun-gimento della piena armonizzazione).

quindi necessario non limitarsi al solo con-cetto di armonizzazione e introdurre il concettocorrelato di interoperabilit. di fatto, nel testo della direttiva InSpIRe nonviene inclusa una definizione esplicita del con-cetto dellarmonizzazione; pur essendone rile-vata limportanza (cfr. il punto 14 delle premes-se), essa viene vista come il risultato di un pro-cesso da attivare e sostenere nel tempo. Inoltre

larmonizzazione spesso citata in forma su-bordinata allinteroperabilit; le stesse regoletecniche di attuazione (le implementing rules)vengono rivolte ad assicurare linteroperabilite poi larmonizzazione, ma solo se questultima fattibile (cfr. lart. 7).al contrario, dellinteroperabilit data una de-finizione estesa allart. 3 (7):

possibilit per i set di dati territoriali di es-sere combinati, e per i servizi di interagire,senza interventi manuali ripetitivi, in modoche il risultato sia coerente e che il valoreaggiunto dei set di dati e dei servizi ad essirelativi sia potenziato.

Questa definizione sottolinea che linteropera-bilit si applica non solo ai data set ma anchealle componenti software che elaborano questidata set e alle interazioni tra computer: adesempio, il software che implementa un model-lo idrologico potr approvvigionarsi dei dati ne-cessari (portate idriche, topografia del territo-rio, serie storiche meteo, popolazione residen-te, uso del suolo ecc.) interrogando i serverdelle strutture amministrative ciascuna dellequali produce un determinato data set e poi at-tivare una serie concatenata di elaborazioni,chiedendo servizi ai vari server disponibili inrete. Linteroperabilit quindi include larmonizzazio-ne, ma non la presuppone; al contrario, com-pito dellinteroperabilit farsi carico dei proble-mi posti dallassenza o dallinsufficienza dellar-monizzazione. Resta da vedere come possa essere assicura-ta linteroperabilit. Questa una vasta area di-sciplinare, che costituisce da un quarto di se-colo un fertile campo di indagine per la ricercainformatica, in particolare con riferimento aigrandi data base eterogenei (Sheth e Larson1990, Hull 1997, atzeni et al. 2007).per il colloquio tra applicazioni software, sonodisponibili soluzioni consolidate, che realizzanolinteroperabilit tramite webservices appog-giandosi a protocolli come SOap (Curbera etal. 2002) oppure ad architetture come ReST(adamczyk et al. 2011). Trascurando in questasede gli elementi di forza e di debolezza dellediverse soluzioni, il punto su cui fissare qui lat-tenzione costituito dalla possibilit di attivareil colloquio tra applicazioni tramite interfaccestandard, che da una parte possono agevol-mente essere rese note in rete e dallaltra pos-sono mascherare quanto voluto del funziona-mento interno del software che eroga il serviziorichiesto: ci si traduce in una modalit debole(o meglio lasca) di interazione tra applicazioni,che garantisce una grande flessibilit operati-va. per linteroperabilit dei dati, il problema pre-

roma


25

senta aspetti forse pi ardui. due computer ingenerale possono interagire, senza interventiumani, solo in quanto possano conoscere co-me i rispettivi dati sono memorizzati e quale siala loro semantica; devono cio condividere glischemi applicativi e i metadati. passando dadue a n computer, la complessit cresce comen2, se si pretende di condividere schemi e me-tadati tra le n-1 possibili coppie di computer(che dovrebbero inoltre essere note a priori):poich ci solitamente irrealistico, necessa-rio trovare un diverso approccio.Questo diverso approccio si basa sullindivi-duazione e sulla condivisione di k schemi dati(per le varie aree tematiche) pienamente docu-mentati e accettabili da tutte le parti potenzial-mente coinvolte. Ogni sistema si dovr comun-que far carico di realizzare il mapping, cio lacorrispondenza (che sar visibile dagli altri si-stemi) tra questi k schemi condivisi e lo sche-ma realmente in uso nella propria base dati(che resta mascherato e pertanto non deve es-sere conosciuto allesterno). Realizzare questomapping unoperazione di complessit nonbanale (proporzionale a k), ma comunquefattibile (se ogni schema dati condiviso ade-guatamente generalizzato) e soprattutto non haimpatto sugli altri sistemi (che potranno quindisenza vincoli modificare la propria partecipa-zione al processo di interoperabilit).Si passa in questo modo (che si pu realizzarecon varie soluzioni tecniche) dallarmonizzazio-ne di tutti gli schemi interni delle singole basidati allarmonizzazione delle interfacce esterne,senza quindi andare a modificare i dati del pas-sato (i c.d. dati legacy) e quindi senza vanifica-re gli investimenti pregressi (spesso ingenti).Tuttavia, resta da sostenere il costo di trasfor-

mazione dei dati verso lo schema condiviso.per i nuovi data set, ovviamente sar opportunoprevederne la produzione direttamente in accor-do con gli schemi condivisi, evitando quindi lo-nere di trasformazione. Sul lungo termine, quin-di, gli n sistemi appaiono convergere sugli stes-si k schemi applicativi; conseguentemente, i lo-ro data set tendono ad essere armonizzati. vacomunque considerato che questo sar un pro-cesso inevitabilmente lungo: oltre al tempo ne-cessario per la fisiologica sostituzione dei dataset preesistenti con i nuovi data set armonizzati,gli stessi schemi dati condivisi sono sempresoggetti ad evoluzioni e ad integrazioni, che perquanto necessarie avranno anche leffetto diriallargare il divario tra schemi armonizzati eschemi attualmente impiegati. Conseguente-mente, le tecniche e gli strumenti che assicura-no linteroperabilit dei dati saranno comunquesempre necessari, sia pure parzialmente.

I fondamenti di INSPIREdopo aver esaminato le principali motivazioniper lavvio del processo di realizzazione di unaSdI e le principali problematiche tecniche chevanno affrontate nel corso di questo processo, opportuno delineare gli aspetti normativi pro-pri di InSpIRe.InSpIRe (cui dedicato il sito europeohttp://inspire.ec.europa.eu/) si fonda sulla omo-nima direttiva del 2007, costituita da 35 puntidi premessa, da 26 articoli e da 3 allegati tec-nici; gli allegati elencano 34 categorie temati-che di dati territoriali (spatial data themes) a di-versa priorit.La direttiva si basa sui seguenti principi(espressi al punto 6 della premesse nel testodella direttiva):

roma


26

Le infrastrutture per linformazione territo-riale degli Stati membri dovrebbero esserefinalizzate a garantire che i dati territorialisiano archiviati, resi disponibili e conservatial livello pi idoneo; devono consentire di combinare in manieracoerente dati territoriali provenienti da fontidiverse allinterno della Comunit e di con-dividerli tra vari utilizzatori e applicazioni; devono permettere di condividere i dati ter-ritoriali raccolti ad un determinato livellodellamministrazione pubblica con altre am-ministrazioni pubbliche; devono rendere disponibili i dati territoriali acondizioni che non ne limitino indebitamen-te luso pi ampio; devono infine far s che sia possibile ricer-care facilmente i dati territoriali disponibili,valutarne agevolmente lidoneit allo scopoe ottenere informazioni sulle loro condizionidi utilizzo.

Sempre nella premessa, il punto 1 afferma:Le informazioni, comprese quelle territoria-li, sono necessarie anche per la formulazio-ne e lattuazione di questa e di altre politi-che comunitarie, che devono integrare di-sposizioni di protezione dellambiente;

mentre il punto 4 ribadisce:LInfrastruttura per linformazione territoria-le nella Comunit europea, INSPIRE, do-vrebbe assistere la definizione delle politi-che in relazione alle politiche e alle attivitche possono avere un impatto diretto o in-diretto sullambiente.

Insieme, i due punti definiscono il contesto del-la direttiva; poich le informazioni territoriali so-no pervasive, la direttiva ha impatto ben al di ldel solo ambiente.Loggetto della direttiva sono i data set (insiemi

di dati territoriali) in formato elettronico di cui lapubblica amministrazione (in senso ampio) di-spone per le sue finalit, nonch un insieme diservizi su rete applicabili a questi data set. Loscopo della direttiva la creazione di una SdIeuropea basata sulle SdI degli Stati membri: esplicitamente descritta una infrastruttura fede-rativa, che si concretizza in un geoportale eu-ropeo (ora disponibile a ) che opera da colle-gamento tra i geoportali degli Stati membri. prevista, in cooperazione con analoghe iniziati-ve europee e internazionali (ad es. ISO e OGC),la redazione di specifiche norme tecniche che ri-guardano principalmente le seguenti aree: metadati (metadata); dati (data specification); servizi di rete (network services); condivisione di dati e servizi (data and ser-

vice sharing).Mentre escluso che dalla direttiva sorganonuovi obblighi di raccolta di dati (la materia regolata da varie altre direttive), lart. 7 (3) pre-vede unapplicazione delle norme tecniche dif-ferenziata per i nuovi data set (cui si applicanotutte le norme tecniche) e per i data set preesi-stenti (di cui si devono rendere disponibili i me-tadati e di cui si deve comunque assicurare lin-teroperabilit tramite il servizio di conversione).La direttiva deve essere recepita nelle singolelegislazioni nazionali (lItalia lha fatto nel 2010,come pi sopra ricordato). La Commissione hala possibilit di modificare il contenuto degliannessi e di emanare misure di esecuzione(implementing rules) esecutive tramite atti chenon necessitano di ulteriore recepimento e chequindi sono immediatamente applicabili allin-terno degli Stati membri dellUe: ci garantisceuno snello processo di aggiornamento dellenorme tecniche.

roma


27

INSPIRE in ItaliaCome ogni altro Stato membro, lItalia deverealizzare una sua SdI, coordinando quelle dilivello sub-nazionale. Questa SdI costituisce unnodo dellinfrastruttura europea e rende dispo-nibili dati territoriali, metadati e servizi di rete(le cui definizioni sono fornite dallart. 3 delladirettiva): dati territoriali: sono quelli afferenti ai data

themes elencati nei tre annessi, in posses-so della pubblica amministrazione (ma an-che dei privati) e disponibili in formato elet-tronico;

metadati: sono le informazioni che descri-vono i set di dati territoriali e i servizi relativiai dati Territoriali e che consentono di ricer-care, repertoriare e utilizzare tali dati e ser-vizi;

servizi di rete: sono servizi accessibili in re-te in quanto indispensabili per condividerei dati territoriali tra i vari livelli di amministra-zione pubblica della Comunit e necessariper ricercare, convertire, consultare e sca-ricare i dati territoriali e per richiamare ser-vizi di dati territoriali e di commercio elettro-nico (punto 17 della premessa).

Il decreto legislativo 27 gennaio 2010, n. 32, ha

affidato al Ministero dellambiente e della Tuteladel Territorio e del Mare (MaTTM) la competen-za degli adempimenti relativi ad InSpIRe; ilMaTTM (che assume quindi la veste di NationalContact Point) assistito operativamente dallI-stituto Superiore per la protezione e la Ricercaambientale (ISpRa). va notato che questo de-creto legislativo, nel recepire la direttiva InSpI-Re, si preoccupato di creare una cornice diraccordo con quanto gi disponibile in Italia. In particolare, il punto I dellart. 2 fornisce laseguente definizione di autorit pubblica il cuipatrimonio informativo interessato da InSpI-Re:autorit pubblica:1. qualsiasi amministrazione pubblica, a livel-

lo statale, regionale o locale, le aziende au-tonome e speciali, gli enti pubblici ed i con-cessionari di pubblici servizi, gli organiconsultivi pubblici;

2. qualsiasi persona fisica o giuridica cheeserciti funzioni amministrative pubbliche,ivi compresi compiti, attivit o servizi speci-fici aventi attinenza con lambiente;

3. qualsiasi persona fisica o giuridica che ab-bia responsabilit o funzioni pubbliche opresti servizi pubblici aventi attinenza con

roma


28

lambiente sotto il controllo degli organi odelle persone di cui ai numeri 1) o 2).

Lart. 3 definisce la SdI italiana in termini di In-frastruttura nazionale per linformazione territo-riale e del monitoraggio ambientale costitui-ta da:a. i metadati, i set di dati territoriali e i servizi

relativi ai dati territoriali e del monitoraggioambientale;

b. i servizi di rete di cui allarticolo 7;c. le tecnologie necessarie alla realizzazione

dei servizi di rete;d. lelenco ufficiale delle autorit pubbliche re-

sponsabili della disponibilit dei set di datiterritoriali di cui allarticolo 1, comma 3, edei servizi ad essi relativi;

e. lindice dei cataloghi pubblici dellinforma-zione ambientale;

f. gli accordi in materia di condivisione, ac-cesso e utilizzo dei dati;

g. i meccanismi, i processi e le procedure dicoordinamento e monitoraggio stabilite, at-tuate o rese disponibili conformemente alpresente decreto.

Queste definizioni sono sostanzialmente analo-ghe a quelle della direttiva InSpIRe (pi soprariportate) ma introducono un maggiore livello didettaglio; si noti come vengano esplicitati duecomponenti: la tipizzazione degli attori/destinatari della

normativa; lindice dei cataloghi dellinformazione am-

bientale previsti dal decreto legislativo 19agosto 2005, n. 195 (attuazione della diret-tiva 2003/4/Ce sullaccesso del pubblicoallinformazione ambientale).

Inoltre, anche in riferimento al Codice dellam-ministrazione digitale (Cad) di cui al decretolegislativo n. 82 del 2005 e successivi aggior-namenti, si stabilisce che: il catalogo nazionale dei metadati relativi ai

set di dati territoriali corrisponde al Reperto-rio nazionale dei dati territoriali (RndT);

i set di dati territoriali di interesse generaledocumentati da RndT includono i set di da-ti territoriali e i servizi corrispondenti alle ca-tegorie tematiche elencate agli allegati I, IIe III (in termini tecnici, il profilo italiano deimetadati include il profilo InSpIRe);

i servizi di rete sono erogati nellambito delSistema pubblico di Connettivit e Coope-razione (SpC);

linteroperabilit di dati e servizi si realizzanel contesto della rete SInanet;

il Geoportale nazionale (ridenominazionedel preesistente portale cartografico nazio-nale) costituisce il punto di accesso nazio-nale InSpIRe ai servizi di rete (tramiteRndT), ai cataloghi delle autorit pubblichee alla rete SInanet.

La produzione di dati ambientali e territoriali generalmente cura del livello amministrativoregionale. Rilevare cosa avviene a questo li-vello fornisce indicazioni affidabili sullo statoconcreto di avanzamento del processo diadesione alla direttiva; in particolare, lindivi-duazione e la pubblicizzazione dei metadatisono oggetto di monitoraggio annuale (Rotun-do, 2013).

Lapplicazione delle norme INSPIRELe attivit di applicazione delle norme InSpIRepossono essere viste sostanzialmente in rela-zione a metadati, dati e servizi di rete. Questeattivit si basano su: le Implementing Rules e le Technical Gui-

delines proposte da InSpIRe; le norme italiane applicabili, principalmente

definite a cura di agId (lagenzia per lItaliadigitale della presidenza del Consiglio);

gli standard internazionali (in particolare:ISO e OGC) referenziati dalle normative dicui ai due punti precedenti.

InSpIRe rende disponibili due punti di accessoa livello europeo: il geoportale per dati e servizi; il sito http://inspire.ec.europa.eu/index.cfm

per norme, implementing rules e altro.Inoltre, il Registry(http: //inspire.ec.europa.eu/registry/) rende di-sponibili elementi (come liste di codici, insiemidi definizioni standard, valori ammessi per imetadati) che sono gestiti centralmente e cui sideve far riferimento, in particolare per lo svilup-po di applicazioni software. Il contesto concet-tuale del modello di interoperabilit di InSpIRe esposto da Tth et al. (2013).

MetadatiLart. 5 della direttiva prescrive:I metadati contengono informazioni sui se-guenti aspetti:a) conformit dei set di dati territoriali alle di-

sposizioni di esecuzione di cui allarticolo 7,paragrafo 1;

b) condizioni applicabili allaccesso a e alluti-lizzo dei set di dati territoriali e dei serviziad essi relativi e, se del caso, corrispon-denti canoni;

c) qualit e validit dei set di dati territoriali;d) autorit pubbliche responsabili della crea-

zione, gestione, manutenzione e distribu-zione dei set di dati territoriali e dei serviziad essi relativi;

e) limitazioni dellaccesso del pubblico e motividi tali limitazioni, a norma dellarticolo 13.

Ogni ente deve attribuire ai suoi data set (sin-golarmente o riuniti in collezioni) e ai servizi direte di sua competenza i metadati che ne con-

roma


29

sentono lindividuazione, la valutazione e lim-piego da parte di altri enti. Sul sito InSpIRe (http://inspire.ec.europa.eu/in-dex.cfm/pageid/101/list/2) sono disponibili: le Implementing Rules (obbligatorie), che

sono state pubblicate come allegato al Re-golamento (Ce) n. 1205/2008 della Com-missione del 3 dicembre 2008 recante at-tuazione della direttiva 2007/2/Ce del parla-mento europeo e del Consiglio per quantoriguarda i metadati;

le Technical Guidelines (informative), chefanno riferimento agli standard en ISO19115 and en ISO 19119.

va notato che le Implementing Rules (pubbli-cate nel 2008) espongono i metadati necessariallindividuazione (discovery) dei dati e dei ser-vizi; le Technical Guidelines (aggiornate nel2013) includono anche i metadati richiesti dalleImplementing Rules on the Interoperability ofSpatial Datasets and Services per il supportoallinteroperabilit (evaluation and use) nonchaltri metadati che sono risultati necessari persingoli temi degli allegati di InSpIRe (come in-dicato dalle Data Specifications Technical Gui-delines). Con questa differenza di date (2013rispetto a 2008) dei due documenti, i riferimentidi letteratura ai metadati InSpIRe prendonogeneralmente in considerazione i soli metadatidi discovery; questa limitazione, anche se pre-vedibilmente verr superata nel prossimo futu-ro, tuttavia fonte potenziale di incongruenze eva quindi tenuta presente.

nello specifico, per un set di dati vero che imetadati richiesti da RndT includono i metada-ti di discovery di InSpIRe (come pi sopra ri-cordato, il profilo RndT include il profilo InSpI-Re); questo per potrebbe non essere ancoravero quando si dovesse tener conto degli altrimetadati richiesti da InSpIRe (cui presumibil-mente potrebbero aggiungersene altri in futu-ro). Ci aggiunge un ulteriore livello di com-plessit alla metadatazione, gi di per s one-rosa (soprattutto quando venga effettuata intempi successivi alla produzione dei dati o allacreazione dei servizi), dovendosi comunqueassicurare il rispetto di entrambe le norme In-SpIRe e RndT.Il risultato finale della metadatazione sostan-zialmente un file in formato XML che viene pub-blicato su di un sito corredato di funzionalit dicatalogazione e di ricerca. Il geoportale InSpI-Re rende disponibile una interfaccia grafica(http://inspire-geoportal.ec.europa.eu/editor/),che supporta lattribuzione dei metadati, non-ch uno strumento di validazione (rispetto allanormativa InSpIRe) dei metadati gi eventual-mente attribuiti (http://inspire-geoportal.ec.eu-ropa.eu/validator2/). anche i maggiori produttori di software GISproprietario (a partire da eSRI e da Inter-graph) nonch molte soluzioni open source(ad es. Geonetwork http://geonetwork-open-source.org/ oppure Geoportal Server, prodottoda eSRI ma rilasciato come open sourcehttp://www.esriitalia.it/prodotti.html/394.html)

roma


30

hanno realizzato strumenti simili a quelli delgeoportale InSpIRe. per lItalia, RndT offreagli enti della pubblica amministrazione variemodalit di gestione e di pubblicazione deimetadati: una interfaccia con accesso controllato alle

funzionalit; un approccio pi leggero, basato su di un

foglio di calcolo (sviluppato dal progettoeuropeo GeoSmartCities);

un accesso tramite plug-in specifici di pro-dotti come Geonetwork o eSRI GeoportalServer.

per approfondimenti sia concettuali che opera-tivi sui metadati, in particolare per le interdipen-denze tra gli standard ISO, OGC e InSpIRe, sipu far riferimento a Litwin e Rossa (2011).

DatiIn relazione ai dati, da una parte la direttiva In-SpIRe esplicitamente non impone nulla: nonchiede di raccogliere nuovi dati, non chiede dimodificare le attuali basi di dati (basta trasfor-marle quando necessario). daltra parte, comevedremo pi avanti, limpatto sulla progettazio-ne delle nuove basi dati e sulla manutenzionedelle basi dati preesistenti forte.Lart. 8 della direttiva prescrive il contenuto del-le Implementing Rules: Le disposizioni di esecuzione riguardano iseguenti aspetti dei dati territoriali:a) una struttura comune per una identificazio-

ne univoca degli oggetti territoriali, in cui sipossono mappare gli identificatori dei siste-

mi nazionali, al fine di assicurarne lintero-perabilit;

b) la relazione tra oggetti territoriali;c) gli attributi chiave e i corrispondenti tesauri

multilingue comunemente necessari per lepolitiche che possono avere ripercussionidirette o indirette sullambiente;

d) informazioni sulla dimensione temporaledei dati;

e) aggiornamenti dei dati.di fatto, si tratta di utilizzare (il pi possibile) unapproccio bottom up: si prendono le Data Spe-cifications (che forniscono gli schemi dei sin-goli temi InSpIRe) disponibili ahttp://inspire.ec.europa.eu/index.cfm/pageid/2/list/2 e si passa a progettare lo schema concet-tuale della intera base dati come composizionedi questi schemi tematici (eventualmenteestendendoli, facendo ricorso alle propriet diereditariet e di generalizzazione delle classi).per le basi dati preesistenti, un aspetto moltoimportante la trasformazione degli schemi at-tuali negli schemi di InSpIRe. esistono stru-menti (ad es. HaLe http://www.esdi-commu-nity.eu/projects/hale) che supportano questatrasformazione (similmente a quanto un toolIde supporta lo sviluppo del software), ma nonci sono scorciatoie: si tratta di rifare lanalisiconcettuale di ogni base dati esistente per in-dividuare le corrispondenze (campo per cam-po, tabella per tabella) tra sorgente e target.Queste corrispondenze in principio possonoessere tutte di tipo 0..*: ogni campo (sorgenteo target) pu corrispondere a nessuno, ad uno

o a pi campi (target o sorgente). Gli schemiInSpIRe dichiarano quali elementi sono obbli-gatori, opzionali o anche voidable (questa qua-lificazione denota un dato che richiesto daInSpIRe ma che, se non presente nella basedati attuale, pu essere tralasciato).In questa situazione, solo limpiego di adegua-te competenze professionali (sia legate al do-minio di conoscenza in esame sia afferenti allaprogettazione informatica) pu condurre versouna soluzione soddisfacente (riprendendo lasimilitudine con gli Ide, ci che accade perlo sviluppo del software: sono richieste capa-cit applicative, al di l della disponibilit deltool di supporto). daltra parte, lecito domandarsi se la con-cessione di InSpIRe di lasciare immutate lebasi dati esistenti non sia in qualche modo af-fetta da un certo grado di ipocrisia: di fatto, al-meno per i casi pi rilevanti, dopo aver consu-mato risorse ingenti per ri-analizzare la basedati e individuarne la conversione verso InSpI-Re, ridisegnarla in pieno accordo con InSpIRee riempirla travasandovi i vecchi contenuti puessere solo una scelta di buon senso ingegne-ristico, in termini di salvaguardia dellinvesti-mento e di compatibilit con il futuro. Ci evitadi doversi far carico della realizzazione delsoftware richiesto dallo specifico servizio diconversione (richiesto dallart. 11 della diretti-va, come pi avanti indicato).di fatto, la direttiva impone come scadenzetemporali per il completamento di queste tra-

sformazioni dei dati esistenti le date del 23 no-vembre 2017 per i temi dellallegato I e del 21ottobre 2020 per i temi degli altri due allegati.da un lato certamente ci tiene conto dellone-rosit delle trasformazioni; dallaltro lato proba-bilmente si fatto affidamento sulla durata delnormale ciclo di vita dei dati, per ipotizzare chea queste date lammontare dei dati pregressiancora attivi possa essere di limitata esten-sione.

Servizi di rete opportuno ricordare che InSpIRe globalmen-te fa riferimento a tutti i possibili servizi relativi adati; a questi possibili servizi, se disponibili surete, devono applicarsi i metadati opportuni.nellart. 11 della direttiva, invece, si fa riferi-

mento ad un set di cinque servizi di rete chedevono essere istituiti dagli Stati membri (sucui ricade anche lonere di gestire la rete ne-cessaria):a) servizi di ricerca che consentano di cercare

i set di dati territoriali e i servizi ad essi rela-tivi in base al contenuto dei metadati corri-spondenti e di visualizzare il contenuto deimetadati;

b) servizi di consultazione che consentano dieseguire almeno le seguenti operazioni: vi-sualizzazione, navigazione, variazione dellascala di visualizzazione (zoom in e zoomout), variazione della porzione di territorioinquadrata (pan), sovrapposizione dei setdi dati territoriali consultabili e visualizzazio-

roma

31

roma


32

ne delle informazioni contenute nelle legen-de e qualsivoglia contenuto pertinente deimetadati;

c) servizi per lo scaricamento (download) deidati che permettano di scaricare copie diset di dati territoriali o di una parte di essi e,ove fattibile, di accedervi direttamente;

d) servizi di conversione che consentano ditrasformare i set di dati territoriali, ondeconseguire linteroperabilit;

e) servizi che consentano di richiamare servizisui dati territoriali.

Come sempre, Implementing Rules e TechnicalGuidelines sono disponibili sul sito InSpIRe. Lascelta architetturale quella dellarchitetturaorientata ai servizi; i web services si basano sulprotocollo SOap. Tuttavia, altre scelte sono tec-nicamente possibili (come accennato pi so-pra): ci si pu aspettare che queste scelte ven-gano incluse nelle Technical Guidelines in unprossimo futuro.Su questa tematica, tutti i produttori di softwaregeografico (sia proprietario che FOSS) si sonoattivati, fornendo strumenti operativi di livelloadeguato. allutente demandato il compito disfruttare correttamente le funzionalit offerte daquesti strumenti, direttamente o tramite compo-nenti software sviluppate ad hoc.Tuttavia, in accordo con le prescrizioni del Cad

(pi sopra riportate), i web services di InSpIRe(che sostanzialmente si basano sugli standardOWS dellOGC) devono integrarsi con il siste-ma pubblico di connettivit e cooperazione(SpC) e con la rete SInanet. Ci comporta unnecessario lavoro di dettaglio per larmonizza-zione tra i diversi insiemi di standard, che inevi-tabilmente tendono ad evolvere indipendente-mente (dellamico et al. 2009).

ConclusioniCome emerge dagli elementi sopra delineati,InSpIRe si inserisce in un filone di ricerca e diapplicazione ben consolidato, ci che ne ga-rantisce la fattibilit tecnica. La Commissioneeuropea, tramite in particolare leea e il JointResearch Centre (JRC), ha fornito un rilevantesostegno normativo e promozionale a questainiziativa, che risponde ad esigenze chiare disemplificazione e di efficacia dellutilizzo e delriutilizzo di dati prodotti da fonti diverse. atti-vo un forum di discussione sui vari aspetti diInSpIRe (http://inspire-forum.jrc.ec.europa.eu/).La rivista IJSdIR tiene traccia degli sviluppitecnici, mentre lannuale Conferenza InSpIRe(nel 2014 tenutasi in danimarca, ad aalborg)consente il confronto e la condivisione di espe-rienze in corso.Il processo di formazione delle regole tecniche

roma


33

tuttavia non stato indenne da approssimazio-ni e ridondanze, per altro forse inevitabili. adesempio, si sarebbero potuti adottare diretta-mente gli standard ISO e OGC, per poi ade-guarli sulla base delle esperienze applicative;invece si dedicato un lungo intervallo di tem-po per adattare questi standard ad un punto divista europeo prima dellapplicazione con-creta, quando poi lapplicazione stessa co-munque ha messo e continua a mettere in evi-denza le parti da modificare. va per altro rico-nosciuto che questo approccio ha consentitodi coinvolgere progressivamente un gran nu-mero di stakeholder, evitando imposizioni re-pentine e quindi facilitando laccettazionedellapproccio InSpIRe nella pratica professio-nale.Innestandosi su di un insieme di esperienzepiuttosto vasto (in particolare derivanti dalprogramma europeo IdaBC http://ec.euro-pa.eu/idabc/, ormai concluso), lapplicazionedi InSpIRe in Italia deve tener conto (di voltain volta, in termini di vincoli o di opportunit)di realizzazioni e normative pregresse, di cuisi dato cenno pi sopra. Queste esperienzepregresse hanno permesso di disporre findallinizio di competenze tecniche adeguatesia nel campo pubblico sia in quello privato.Tuttavia, proprio in quanto pregresse, in alcu-

ni casi si sono evidenziati disallineamenti trale prescrizioni delle Implementing rules equelle delle norme nazionali; questa proble-matica, per altro, inevitabile nel transitorio etrover soluzione nel normale processo dimanutenzione della normativa. per il futuro, pu essere utile sottolineare quan-to segue: la direttiva InSpIRe crea una SdI con riferi-

mento alle politiche dellambiente, di cuiper altro una descrizione piuttosto ampia;conseguentemente, le norme InSpIRe inquanto tali hanno impatto ben al di l delsolo contesto ambientale; si pensi ai datathemes dellallegato I, che sostanzialmentesono di interesse di tutti i domini applicativi(dai trasporti alle smart cities) che si basa-no anche su dati georeferenziati;

di fatto, programmi europei come ISa(http://ec.europa.eu/isa/) hanno gi posto lebasi per creare SdI non settoriali ma esteseallintero spettro di interessi dei cittadini edelle imprese; per il nuovo programma ISa(http://ec.europa.eu/isa/isa2/index_en.htm)sono allocate

Quaderno IORoma III-2015

Documents

Transcript of Quaderno IORoma III-2015