Università di Pisa
Dipartimento di Civiltà e Forme del
Sapere
Corso di Laurea Magistrale
in Archeologia
Anno Accademico 2016/2017
Elaborato finale
Comunicare l'archeologia
attraverso i webGIS:
il caso di Siracusa
Candidato
Marta Tringali
Relatore
Prof.ssa Maria Letizia Gualandi
Correlatore
2
INDICE
Introduzione ... 4
Capitolo 1 - La tecnologia webGIS ... 7
1.1 Dal GIS al webGIS ... 7
1.2 Definizioni ... 8
1.3 Architettura generale di un sistema webGIS ... 10
1.4 Evoluzione delle tecnologie webGIS ... 14
1.6 I benefici dell’approccio Open Source ... 16
1.7 Principali piattaforme webGIS Open Source ... 17
1.8 Standardizzazione dell’informazione geografica: gli standard OGC ... 21
Capitolo 2 - I webGIS archeologici in Italia ... 22
2.1 Archeologia e webGIS ... 22
2.2 Progetto MAPPA ... 25
2.2.1. Descrizione del progetto ... 25
2.2.2. La carica innovativa del Progetto MAPPA ... 28
2.2.3. La struttura dati ... 30
2.2.4. La piattaforma GIS ... 34
2.2.5. II webGIS del Progetto Mappa ... 36
2.3 OPENCiTy Project ... 43
2.3.1. Descrizione del progetto ... 43
2.3.2. Catania, un unicum nel panorama delle città antiche pluristratificate ... 44
2.3.3. La struttura dati ... 45
2.3.4. La piattaforma GIS ... 48
2.3.5. Il webGIS del Progetto OPENCiTy ... 48
2.4 SITAR (Sistema Informativo Territoriale Archeologico di Roma) ... 54
2.4.1. Descrizione del progetto ... 54
2.4.2. L’architettura e i livelli logici del Sistema... 55
2.4.3. Il webGIS SITAR... 58
Capitolo 3 – Il caso studio: Siracusa ... 63
3.1 Introduzione ... 63
3.2 Inquadramento storico ... 64
3
3.4 Inquadramento topografico: gli antichi quartieri cittadini ... 74
Capitolo 4 - Il webGIS archeologico di Siracusa ... 77
4.1 Introduzione ... 77
4.2 Piattaforma tecnologica ... 78
4.3 Descrizione della struttura di geodatabase ... 79
4.4 Descrizione del dataset e organizzazione dei dati ... 81
4.4.1. Introduzione ... 81
4.4.2. Acradina ... 84
4.4.3. Ortigia ... 87
4.4.4. Data entry alfanumerico e geografico ... 92
4.5 Caricamento e gestione dei dati in ambiente GIS desktop ... 94
4.6 Realizzazione dell’interfaccia di consultazione webGIS ... 99
Conclusioni ... 104
Bibliografia ... 106
4
Introduzione
Negli ultimi anni le discipline archeologiche hanno guardato con crescente attenzione alle piattaforme webGIS. Questi potenti strumenti, infatti, sono in grado sia di gestire l’eterogeneità dei dati provenienti da contesti di scavo o di ricognizione favorendo analisi quantitative e spaziali altrimenti non realizzabili sia di facilitare la collaborazione tra esperti di settore e pubbliche amministrazioni. Per la loro stessa natura, inoltre, consentono il libero accesso, tramite la rete, alle informazioni allargando e diversificando di fatto il bacino d’utenza e svolgendo un fondamentale ruolo di disseminazione. E’ evidente, infine, l’importanza che i webGIS archeologici assumono in contesti urbani pluristratificati dove le tracce di un antico passato convivono con lo sviluppo urbano del presente. In città dalla storia millenaria le piattaforme webGIS, infatti, possono rappresentare dei veri e propri strumenti di pianificazione urbanistica ma anche di tutela e fruizione del patrimonio archeologico.
Da queste considerazioni nasce il lavoro di tesi che ha come scopo la realizzazione di una piattaforma WebGIS dedicata all’archiviazione, gestione e fruizione del patrimonio culturale e archeologico della città di Siracusa e fa parte del progetto “OpenSiracusa” dell’Istituto dei Beni Archeologici e Monumentali del CNR di Catania (CNR IBAM).
La scelta di operare in tale città nasce dall’importanza e dalla mole delle sue testimonianze storico-archeologiche, riflesso di una storia millenaria senza alcuna soluzione di continuità dalla preistoria ai giorni nostri. Allo stato attuale l’alta frammentarietà del patrimonio archeologico di Siracusa, spesso frutto di indagini non sistematiche, rende quanto più attuale e urgente il problema del rapporto tra passato e presente, tra l’esigenza di tutelare e valorizzare il patrimonio culturale e le necessità di una città moderna.
Il webGIS, rappresenterà quindi un valido strumento di supporto sia alla ricerca scientifica, che potrà beneficiare di un completo repertorio sul patrimonio storico-archeologico di Siracusa, sia a tutti coloro che a vario titolo si occuperanno della gestione, tutela e valorizzazione del patrimonio culturale della città.
Data la complessità del contesto archeologico siracusano, è importante sottolineare come non sia negli scopi del lavoro di tesi quello di realizzare un sistema webGIS completo e che racchiuda al suo interno tutte le emergenze
5 archeologiche della città. L’obiettivo primario è essenzialmente la realizzazione di un progetto pilota, consistente in una piattaforma di consultazione geografica dei primi dati raccolti, che dimostri l’efficacia e le possibilità di interrogazione e disseminazione di questi strumenti di fronte a banche dati archeologiche caratterizzate da notevoli problematiche sia per la loro intrinseca complessità nello sviluppo spazio-temporale sia per la frammentazione e la non standardizzazione delle informazioni contenute.
Dal punto di vista del modello operativo, la struttura dati e l’implementazione tecnologica del webGIS realizzato derivano direttamente dalle esperienze del Progetto MAPPA e di OpenCity riguardanti le città di Pisa e Catania.
In particolare, l’interfaccia ed il motore webGIS sono sostanzialmente simili a quelle utilizzate nell’ambito del Progetto MAPPA dell’Università di Pisa (coordinato dalla Prof.ssa Maria Letizia Gualandi) che rappresenta di fatto la prima esperienza strutturata italiana di pubblicazione e apertura dei dati archeologici in ambito urbano.
La struttura di database relazionale utilizzata è invece quella di OpenCiTy, il progetto riguardante la città di Catania (coordinato dal Dott. Daniele Malfitana dell’Istituto dei Beni Archeologici e Monumentali del CNR) dal quale deriva OpenSiracusa.
La struttura delle tesi è stata articolata in quattro capitoli. La tecnologia webGIS è la tematica principale del primo capitolo, nel quale è stata descritta l’architettura generale di questi sistemi e la loro evoluzione. Data la notevole diffusione e l’affidabilità raggiunta, è stata inoltre effettuata una breve descrizione delle principali piattaforme Open Source utilizzate in questo ambito, illustrando i principali benefici dei sistemi a codice aperto.
Nel secondo capitolo, è stato affrontato il rapporto tra archeologia e webGIS facendo riferimento alle tre principali esperienze italiane che hanno applicato un approccio multidisciplinare allo studio del patrimonio archeologico con la realizzazione di webGIS archeologici strutturati: Progetto MAPPA (Pisa), OpenCiTy (Catania), SITAR (Roma).
Nel capitolo successivo, il terzo, si è preso in esame il caso-studio della città di Siracusa con un inquadramento storico generale, la storia della ricerca archeologica e infine lo sviluppo topografico della città.
6 Infine, nell’ultimo e conclusivo capitolo sono state descritte le attività svolte per la realizzazione del webGIS archeologico di Siracusa in dettaglio: la definizione della piattaforma tecnologica utilizzata, illustrando la struttura di geodatabase e le caratteristiche del dataset archeologico fornito da CNR IBAM, l’organizzazione dei dati in ambiente GIS desktop e la realizzazione finale dell’interfaccia di consultazione webGIS.
7
Capitolo 1 - La tecnologia webGIS
1.1 Dal GIS al webGIS
I sistemi informativi geografici (GIS, Geographic Information System) possono essere definiti come una “combinazione di hardware, software, risorse umane e procedure che ha lo scopo di acquisire, gestire e analizzare dati spazialmente referenziati”1.
Hanno vissuto negli ultimi anni un notevole sviluppo e una forte evoluzione tecnologica derivata dall’esigenza di dover gestire ed elaborare una grande mole di dati e informazioni relativi al territorio che in passato avevano come principale supporto di riferimento quello cartaceo. Tale passaggio, favorito dalla crescente disponibilità di dati e dall’evoluzione delle tecnologie hardware e software, è stato anche di tipo culturale in quanto ha portato alla presa di coscienza della complessità spaziale in cui viviamo2.
Per decenni la maggior parte delle informazioni geografiche sono state utilizzate da parte di operatori del settore tramite applicazioni GIS desktop professionali sviluppate per un utilizzo monoutente o per condivisione in rete locale, restringendo di fatto il pubblico che ne poteva beneficiare.
La fruibilità dei sistemi informativi geografici è cambiata in modo radicale grazie al crescente utilizzo di Internet e alle potenzialità del Web 2.0 caratterizzato dalla presenza di piattaforme di condivisione di dati, dalla forte spinta all’interazione tra utenti e dalla generazione di contenuti da parte di questi ultimi. Il passaggio da un fase iniziale in cui l’accesso era riservato esclusivamente a esperti del settore ad un modello partecipativo ha permesso la diffusione e lo sviluppo di piattaforme geografiche sempre più aperte al grande pubblico.
Tale passaggio ha visto nascere i webGIS, piattaforme geografiche condivise nella rete con specifiche finalità di comunicazione e condivisione delle informazioni territoriali.
Il concetto di comunicazione nell’informazione geografica è particolarmente importante e sta alla base di questi strumenti, rendendo spesso la loro esistenza strettamente legata all’efficacia della diffusione delle informazioni stesse.
1 GOODCHILD, KEMP 1990 2 NOTI 2014
8 Parallelamente la disponibilità di interfacce utente sempre più intuitive e usabili, la possibilità di utilizzare i sistemi webGIS senza necessità di particolari competenze informatiche e l’incremento delle velocità di connessione alla rete hanno permesso la massiccia diffusione di queste piattaforme.
Le tecnologie webGIS vengono oggi applicate con successo negli ambiti più diversi: urbanistica e pianificazione territoriale, monitoraggio ambientale, geologia, logistica e mobilità, agronomia e gestione forestale, protezione civile, studi socio-sanitario, beni culturali e archeologia, ecc.
Grazie e a questi strumenti, un pubblico di utenti sempre più ampio ha avuto la possibilità di accedere all’informazione geografica incrementando l’efficacia della comunicazione da parte di enti territoriali e strutture pubbliche e private. Questi benefici hanno agevolato anche una politica di trasparenza e di avvicinamento ai soggetti coinvolti e, in particolare, alla cittadinanza garantendo virtuosi processi partecipativi altrimenti non possibili.
Come verrà illustrato nel prosieguo di questo lavoro di tesi, queste caratteristiche risultano particolarmente evidenti nel campo dei beni culturali e dell’archeologia dove si intrecciano in maniera molto forte le tematiche della comunicazione, della partecipazione e della complessità geografica.
1.2 Definizioni
Con il termine webGIS si indica un insieme di tecnologie che permettono la visualizzazione, la gestione e l’analisi di dati geospaziali in reti Internet e Intranet sfruttando alcune delle funzionalità derivanti dai software GIS3.
Dal punto di vista tecnico la pubblicazione delle informazioni geografiche in rete si basa nella maggior parte dei casi su tecnologie di tipo client-server, tipiche dell’architettura web con utilizzo del protocollo standard HTTP4 (HyperText
Transfer Protocol).
Solitamente l’accesso alle applicazioni webGIS avviene attraverso un normale browser compatibile W3C5 (es. Mozilla Firefox, Google Chrome, MS Internet
Explorer, ecc.). Attraverso di esso, l’utente invia una richiesta al server che, dopo
3 http://www.gfoss.it/drupal/webgis
4 https://it.wikipedia.org/wiki/Hypertext_Transfer_Protocol 5 https://www.w3.org/
9 averla elaborata, produce una risposta sottoforma di stringhe di informazioni o immagini da rinviare al client. Tuttavia, è importante mettere in evidenza come le modalità di fruizione dei servizi erogati da un webGIS siano ormai fortemente differenziate e non più legate strettamente all’utilizzo di un browser web (Fig. 1.1).
Fig. 1.1 – Differenti modalità di fruizione di un sistema webGIS (da https://geomappando.com/)
Le mappe fornite da un webGIS possono infatti essere consultate e gestite attraverso vari componenti software quali, ad esempio, applicazioni installate su dispositivi mobili, applicazioni desktop (GIS e non), server GIS che a loro volta erogano come servizio le stesse mappe ad altri utenti.
Negli ultimi anni si è generata una certa confusione nell’utilizzo dei termini
webGIS e web mapping. In linea generale, il termine web mapping è stato
utilizzato per le applicazioni online che fornivano un servizio di consultazione di mappe su web senza alcuna funzionalità di analisi e gestione tipiche dei GIS. I servizi come Google Maps6 e Bing7, per citare i più conosciuti, possono essere
considerati facenti parte di questa categoria di applicazioni che ha avuto come scopo principale quello di raggiungere una vasta utenza aumentando l’interattività e l’usabilità generale nella consultazione delle mappe su web.
6 https://maps.google.it/maps 7 https://www.bing.com/maps
10 Secondo questa accezione, è corretto considerare le applicazioni di web mapping come un sotto-insieme di quelle webGIS (Fig. 1.2) che, oltre alle funzionalità di consultazione e diffusione delle mappe, prevedono attività di analisi e gestione dei dati geografici ad uso di un’utenza solitamente più tecnica o specifica del settore di interesse8.
Fig. 1.2 - Applicazioni di web mapping sotto-insieme di quelle webGIS (da https://geomappando.com/)
Recentemente tuttavia la differenziazione tra queste tipologie di applicazioni è risultata sempre più sfumata poiché molti servizi di web mapping hanno recepito le funzionalità di base dell’analisi spaziale e della ricerca geografica diventando di fatto sempre più assimilabili a sistemi webGIS.
1.3 Architettura generale di un sistema webGIS
L’architettura generale di un sistema webGIS prevede l’utilizzo di segmenti server separati per l’erogazione dei vari servizi. In particolare, possiamo distinguere i seguenti componenti che, nelle configurazioni più semplici, possono essere racchiusi all’interno di un’unica macchina server (fisica o virtuale) (Fig. 1.3):
- Database Server
- Server delle mappe (o GIS Server o Map Server) - Web Server
- Client (browser) che permette agli utenti di interagire con dati geografici
11
Fig. 1.3 – Componenti del sistema webGIS (da http://www.geosys.com.tr)
Il server delle mappe (GIS Server) rappresenta senza dubbio il componente principale dell’infrastruttura e ha come scopo quello di gestire l'interazione tra il client e i dati geografici. Solitamente il server delle mappe svolge i sui compiti utilizzando le funzionalità di specifici software che di fatto rappresentano i motori dell’applicazione webGIS (es. UMN MapServer9, Geoserver10, QGIS Server11,
ecc.).
I dati geografici possono essere archiviati direttamente sul file system del server o, più comunemente, all’interno di un database geografico ubicato sul Database Server.
I geodatabase (database spaziali o Spatial DBMS) sono archivi di dati geografici memorizzati su database relazionali (RDBMS, Relational DataBase Management
System) e non su file system. Sono in grado non solo di immagazzinare geodati
ma anche di fornire funzionalità di elaborazione e analisi spaziali spesso molto evolute12. 9 http://mapserver.org/ 10 http://geoserver.org/ 11 http://www.qgis.org/it/site/ 12 NOTI 2014
12 Tra i formati di geodatabase più diffusi possiamo citare PostgreSQL/PostGIS13,
Oracle Spatial14, MySQL Spatial15, SQLite/SpatialLite16.
Infine, l’interfaccia software tra il server delle mappe e la rete Internet esterna è gestita dal Web Server (es. Apache HTTP Server17, Microsoft IIS18, ecc.).
Il modello client-server sopra descritto prevede solitamente una notevole interazione con il server con carico computazionale sbilanciato verso quest’ultimo.
La strategia server-side è basata infatti sulla fornitura di dati GIS "on demand" da un server delle mappe che ha accesso sia ai dati, sia al software necessario ad elaborare i dati stessi. Il client non ha quindi bisogno di una grossa potenza di calcolo ma necessita solamente della capacità di sottomettere richieste e visualizzare risposte attraverso il web browser.
In dettaglio, l’interazione client-server viene avviata dall’utente con una richiesta effettuata dal browser. Tale richiesta, inviata attraverso la rete (Internet o Intranet) è recepita ed elaborata dal server che risponde con un output (alfanumerico o grafico) rinviato al browser (Fig. 1.4).
Fig. 1.4 - Interazione client-server
13 http://www.postgis.net 14 http://www.oracle.com 15 https://www.mysql.com 16 https://www.sqlite.org/ 17 http://www.apache.org/ 18 https://www.iis.net/
13 La parte più importante di questa architettura è sicuramente il server delle mappe sul quale è installata un’applicazione GIS (map generator o map server) che garantisce la produzione dinamica degli output richiesti dall’utente e l’interfaccia con il web server. In una architettura di questo tipo il server web agisce quindi da intermediario tra il client (browser) e il map server.
L’architettura sopra descritta viene definita three tier architecture (architettura webgis su tre livelli) ed ha come vantaggio principale quello di agevolare l’accesso a dataset molto grandi e complessi che normalmente sarebbero difficili da trasferire attraverso la rete, anche in presenza di client con bassa potenza di calcolo. Inoltre, si ha la possibilità di un maggiore controllo e validazione su operazioni effettuate dall’utente (es. accesso, editing, query, ecc.) sui dataset. Tuttavia, la strategia server-side prevede un continuo scambio di informazioni tra le componenti client e server con perfomance ed esperienza d’uso molto dipendenti dalle prestazioni lato server e dalla velocità di connessione alla rete. Inoltre, non viene sfruttata la potenza di calcolo del client che si limita ad inviare richieste e visualizzare risposte.
Lo sviluppo tecnologico dei browser ha permesso, in anni recenti, di alleggerire il carico computazionale gravante sui server e ha visto la nascita di applicazioni webGIS in cui il classico scambio client-server è risultato parzialmente o, in alcuni casi, addirittura totalmente sbilanciato verso il lato client.
Le funzionalità di interfaccia e interazione con le mappe delle applicazioni webGIS possono infatti essere gestite attraverso librerie (tipicamente scritte in linguaggio Javascript) richiamabili direttamente dal browser che coadiuvano i software dei server delle mappe.
In questo tipo di approccio il client (browser) invia la richiesta al server che spedisce indietro solamente le informazioni strettamente necessarie per l’elaborazione che effettuerà il client stesso. Quest’ultimo non rappresenta più un mero visualizzatore di dati geografici ma diventa quindi uno strumento capace di elaborarli e gestirli.
La strategia client-side riduce il carico di lavoro del server e il traffico in rete, utilizza la potenza di calcolo del computer dell’utente e soprattutto concede a esso un controllo più elevato sul processo di analisi e consultazione dei dati (es. pan, zoom, controllo della visualizzazione dei layer, query, geoprocessing, ecc.).
14 Inoltre, vengono diminuite le interazioni tra client e server riducendo quindi l’occupazione di banda e agevolando il trasferimento di dati in forma vettoriale. Gli svantaggi di questo approccio riguardano ovviamente la necessità di utilizzo di macchine client sufficientemente potenti.
1.4 Evoluzione delle tecnologie webGIS
Nella prima metà degli anni 90, con l’arrivo e la diffusione di Internet, nacque l’esigenza di condividere informazioni di tipo geografico sia a livello locale che globale.
Il primo passo fu quello di caricare mappe su pagine web statiche tramite il linguaggio HTML19 che permetteva all'utente la visualizzazione delle immagini
escludendo però ogni forma di interazione con esse.
L'avvento dei linguaggi dinamici di programmazione in ambito web ha dato un forte impulso allo sviluppo di applicazioni geografiche interattive. Le prime di queste, rudimentali e lente per gli standard odierni, furono elaborate attraverso le versioni iniziali dei software server MapServer20 e Esri ArcIMS21.
Tuttavia, la portata rivoluzionaria delle mappe dinamiche sul web era indiscutibile; l'idea stessa che tramite un semplice browser si potesse richiedere e visualizzare la mappa utilizzando dinamicamente gli strumenti di navigazione era impensabile fino a qualche anno prima.
In quella fase storica, i problemi dei webGIS riguardavano la velocità di caricamento della mappa e la scalabilità. Il web server, infatti, poteva recepire solo un numero limitato di richieste e non era quindi in grado di gestire molti utenti contemporaneamente.
Questa problematica fu in parte attenuata quando i siti web iniziarono a distribuire mappe mosaicate in “tile” (porzioni), memorizzate nella cache del server. Il server di mappe non rispondeva più con la generazione dinamica della mappa richiesta ma con un mosaico di tiles già ubicate nella cache e con dimensioni e risoluzione dipendenti dalla scala di visualizzazione scelta dall’utente (Fig. 1.5). Questo
19 https://it.wikipedia.org/wiki/HTML 20 http://mapserver.org/
15 sistema garantiva un caricamento più veloce ed una esperienza di navigazione più fluida anche in presenza di molti utenti simultanei.
Fig. 1.5 – Generazione dinamica della mappa tramite mosaico di tiles (da https://www.e-education.psu.edu)
Inoltre, l’avvento della tecnica conosciuta con il nome di AJAX22 (Asynchronous
JavaScript e XML) ha ulteriormente aumentato la velocità e l’usabilità delle
applicazioni webGIS. Con AJAX infatti le richieste vengono gestite senza un aggiornamento fisico dell’intera pagina web: l’utente non vedrà ricaricare l’intera interfaccia dell’applicazione ma solo una porzione della stessa (solitamente la mappa), senza avere l’impressione di essere in attesa di una risposta dal server. A partire dagli anni 2000, infine, la diffusa adozione di dispositivi mobili (smartphone e tablet) ha ulteriormente aumentato la domanda di mappe sul web aggiornando le modalità di fruizione e le interfacce utente rese sempre più minimali e adatte all’interazione di tipo touch- screen.
22 AJAX è una tecnica di programmazione che prevede richieste asincrone tra browser e server garantendo
aggiornamenti di porzioni di pagine e di interi elementi senza dover aggiornare l’intera pagina. Lo sviluppo di applicazioni HTML con AJAX si basa su uno scambio di dati in background fra web browser e server, che consente l'aggiornamento dinamico di una pagina web senza esplicito ricaricamento da parte dell'utente.
16
1.6 I benefici dell’approccio Open Source
Il panorama delle tecnologie webGIS attualmente disponibili è molto variegato e si è progressivamente evoluto negli anni grazie al miglioramento nelle funzionalità dei prodotti commerciali e parallelamente al raggiungimento di un ottimo livello di efficienza e di operatività dei software liberi.
Molte Pubbliche Amministrazioni e aziende hanno sviluppato applicazioni webGIS basate su piattaforme Open Source aumentando fortemente la diffusione di queste tecnologie e la dimensione della comunità di sviluppo. In particolare, il modello di sviluppo open ha influenzato fortemente questo settore con indubbi vantaggi che vanno bel oltre la gratuità dei prodotti. L’accesso al codice sorgente, di per sé una visione eticamente sostenibile, ha permesso una propagazione della conoscenza che ha generato a sua volta nuove applicazioni e modelli di business altrimenti non possibili23 .
I benefici dell’utilizzo di piattaforme GIS e webGIS Open Source sono molteplici. Oltre ai motivi economici e alla sostanziale gratuità di tali soluzioni che non necessitano di acquisto di licenze o sottoscrizione di abbonamenti, molte strutture hanno approcciato i sistemi Open Source per garantirsi una situazione di indipendenza da fornitori commerciali.
Inoltre, la possibilità di accedere al codice sorgente ha permesso la personalizzazione delle applicazioni e ha dato una notevole spinta nella ricerca di soluzioni ottimizzate per specifiche esigenze.
Infine, anche se risulta complicato definire precise statistiche in questo senso, appare evidente come i benefici sopra indicati abbiano fatto sì che il ciclo di vita delle applicazioni webGIS Open Source risulti mediamente superiore rispetto a quelle delle applicazioni proprietarie.
La problematica del ciclo di vita dei webGIS, particolarmente importante in ambito archeologico e in stretta connessione con le capacità di comunicazione e diffusione della conoscenza, sarà affrontata nei prossimi capitoli di questo lavoro di tesi.
23 NOTI 2014
17
1.7 Principali piattaforme webGIS Open Source
Allo stato attuale esistono numerose soluzioni Open Source per l’erogazione e la gestione dei dati geografici in rete. Risulta particolarmente complicato, ed è al di fuori degli scopi di questo lavoro, definire un quadro esaustivo degli strumenti disponibili. Inoltre, la complessità del quadro generale rende spesso non adeguati i tentativi di classificazione in base a determinati requisiti.
Nonostante ciò, ritengo importante riassumere i principali approcci esistenti per poter meglio comprendere le scelte tecnologiche fatte anche in ambito archeologico e che saranno descritte nei successivi capitoli.
L’approccio classico, descritto in precedenza, riguarda l’implementazione di un Server delle Mappe che eroga i servizi e la componente geografica attraverso un motore GIS. In ambito Open Source, i principali software di questo segmento sono UMN MapServer24, GeoServer25 e QGIS Server26:
- UMN Mapserver. E’ una piattaforma di sviluppo per web mapping finalizzato alla rappresentazione di dati geospaziali. Il progetto è stato avviato originariamente dall’Università del Minnesota (UMN) nel 1996 in cooperazione con il Minnesota Department of Natural Resources (MNDNR) e con la NASA; è attualmente gestito da un team internazionale, amministrato dall’OSGeo27 (Open Source Geospatial Foundation).
È scritto in C, gira su diversi sistemi operativi (Windows,GNU / Linux , Mac OS X, ecc) ed è compatibile con le specifiche dell' Open Geospatial
Consortium e in particolare con gli standard WMS28 (Web Map Service),
WFS29 (Web Feature Service), WCS30 (Web Coverage Service).
L’utilizzo di MapServer dipende dalla conoscenza della sintassi dei suoi file di configurazione (mapfile). E’ caratterizzato da un'ampia interfaccia di programmazione (Mapscript) che permette di interagire col server tramite 24 http://mapserver.org/ 25 http://geoserver.org/ 26 http://www.qgis.org/it/site/ 27 http://www.osgeo.org/ 28 https://it.wikipedia.org/wiki/Web_Map_Service 29 https://it.wikipedia.org/wiki/Web_Feature_Service 30 https://it.wikipedia.org/wiki/Web_Coverage_Service
18 linguaggi come PHP, Python, JAVA, ecc., e può vantare varie soluzioni di interfacce client pronte all'uso che permettono interazioni anche complesse con i dati (es. Pmapper31). UMN Mapserver viene utilizzato
solitamente se si vuole disporre di funzionalità client più complesse e per poter gestire l'accesso ai dati e la loro stilizzazione in maniera semplice tramite la sintassi dei mapfile.
Questo software risulta ad oggi essere uno dei punti di riferimento per applicazioni di web mapping e web service grazie alla robustezza del programma e alla grande comunità di sviluppo e supporto che continua ad alimentare il progetto.
- GeoServer. Nato nel 2003, è un GIS server Open Source scritto in Java che permette agli utenti di condividere, elaborare e modificare dati geospaziali. Fornisce servizi WFST (è possibile editare i dati vettoriali pubblicati quando si decida di rendere pubblico questo servizio), WMS, WCS. Progettato per l'interoperabilità, pubblica dati da qualsiasi fonte che usa standard aperti. La sua installazione può essere effettuata senza grosse difficoltà sia come applicativo "standalone" che richiede l’installazione della Java Virtual Machine, sia come applicazione che si poggia sul webserver Tomcat32. La gestione e la configurazione delle
applicazioni è molto agevolata grazie ad un'interfaccia grafica web di amministrazione particolarmente curata.
- QGIS Server: E’ una soluzione relativamente recente rispetto a UMN Mapserver e GeoServer che si integra perfettamente con il software GIS desktop QGIS. Quest’ultimo mette infatti a disposizione un plugin che permette di esportare un progetto di QGIS desktop in un progetto web per QGIS Server, con i layer e i simboli prescelti basati sullo standard SLD. Dal punto di vista informatico QGIS Server può essere definito come un’applicazione FastCGI/CGI (Common Gateway Interface), scritta in C++, che utilizza la libreria Qt per la componente grafica.
Come accennato in precedenza, la disponibilità della tecnologia AJAX e l’aumento della potenza di calcolo dei computer desktop hanno permesso negli
31 http://www.pmapper.net/ 32 http://tomcat.apache.org/
19 ultimi anni la nascita di interfacce webGIS particolarmente sviluppate. Queste ultime possono essere implementate miscelando linguaggi server e client (es. p.mapper, GIS Client, GeoMoose33) oppure costruite interamente lato client e
costituite da framework e librerie Javascript. Tra esse le più conosciute sono le API (Application Programming Interface) di Google, OpenLayers e LeafletJS. In entrambi i casi, l'utente accede all’applicazione tramite un browser, ma mentre nel primo caso il client esegue le sue elaborazioni sul server (usando un linguaggio, ad esempio, come PHP), nel secondo tutte le elaborazioni vengono eseguite direttamente all'interno del browser (con utilizzo dei linguaggi DHTML e Javascript).
Nel primo gruppo citiamo p.mapper (Fig. 1.6), un front-end di UMN MapServer, sviluppato da Armin Burger, distribuito con licenza GNU34 (General Public
License) e aderente agli standard OGC (Open GeoSpatial Consortium35) WMS e
WFS. p.mapper è in grado di sfruttare al meglio le potenzialità di MapServer attraverso un layout pulito, estremamente intuitivo e nello stesso tempo altamente funzionale.
Fig. 1.6 – webGIS Progetto Mappa (da http://www.mappaproject.org)
Tra le interfacce client la più nota è OpenLayers36 (Fig. 1.7), una libreria
Javascript che non richiede alcuna installazione, in quanto necessita solo di
33 http://www.geomoose.org 34 http://www.gnu.org/
35 http://www.opengeospatial.org/ 36 http://openlayers.org/
20 essere inclusa in una semplice pagina html. Le sue potenzialità sono estremamente ampie. Consente infatti di includere facilmente una mappa all’interno di qualsiasi pagina web usufruendo di servizi di geodati pubblici come OpenStreetMap, Google Maps, Bing, Yahoo Maps, oppure provenienti da GIS Server attraverso servizi WMS, WFS o WCS. In presenza di una sorgente dati esterna (es. GIS Server) la sua implementazione non richiede quindi alcuna configurazione in ambiente server o installazione di software. In quest’ultimo caso, OpenLayers è spesso utilizzato come interfaccia client di GeoServer (Fig. 1.8).
21
Fig. 1.8 – OpenLayers come interfaccia client di GeoServer (da http://geomappando.com/)
1.8 Standardizzazione dell’informazione geografica: gli
standard OGC
La necessità da parte di enti e organizzazioni di acquisire e scambiare dati di carattere geografico richiede la cosiddetta interoperabilità dei dati, che è rivolta ad evitare la ridondanza e non accessibilità degli stessi. In particolare per interoperabilità si intende la capacità di garantire l’interazione tra sistemi non omogenei e lo scambio e/o la condivisione di dati.
In tal senso, l’Open Geospatial Consortium (OGC), un’organizzazione no-profit fondata nel 1994 e formata prevalentemente da aziende, università e agenzie governative, ha emanato delle specifiche tecniche a livello internazionale che definiscono i servizi per l’accesso a informazioni spaziali e consentono l’interoperabilità tra sistemi per lo scambio e la condivisione di dati geografici. Gli standard internazionali OGC più conosciuti sono i servizi web quali WMS (Web Map Service), WFS (Web Feature Service), WCS (Web Coverage Service). Questi servizi cartografici sono denominati in genere OGC Web Service (OWS) e permettono ai software alle interfacce webGIS sopra descritte di connettersi a strati informativi esposti da GIS Server. In particolare, il protocollo più utilizzato è sicuramente il WMS con il quale un server cartografico restituisce immagini georeferenziate in base a richieste dell’utente.
22 A differenza del WMS, il WFS restituisce dati geografici in formato vettoriale mentre il WCS permette di inviare dati in formato raster GRID (ad esempio un Modello Digitale del Terreno) che possono essere analizzati e interrogati attraverso le funzionalità GIS.
Capitolo 2 - I webGIS archeologici in Italia
2.1 Archeologia e webGIS
Negli ultimi anni le discipline archeologiche hanno guardato con crescente attenzione alle piattaforme webGIS. Questi strumenti, infatti, sono in grado sia di gestire l’eterogeneità dei dati provenienti da contesti di scavo o di ricognizione favorendo la collaborazione tra esperti di settore, sia di consentire l’accesso alle informazioni a molte categorie di utenti allargando e diversificando il bacino d’utenza.
Sono molti gli aspetti che rendono questi strumenti rilevanti e per certi aspetti fondamentali nell’ambito dei beni culturali e in particolare in quello archeologico. E’ importante sottolineare come le applicazioni webGIS riescano a coinvolgere maggiormente i non addetti ai lavori nei processi di elaborazione e di conservazione della memoria storica, trasmettendo l’importanza della ricerca storica ed archeologica non solo per fini accademici, ma con più vasti obiettivi politico-sociali di tutela e valorizzazione.
Da un punto di vista operativo, migliorano l’efficienza del lavoro nel settore dell’amministrazione dei Beni Culturali, creando maggiore comunicazione tra le Soprintendenze e le Amministrazioni territoriali (Comuni, Provincie e Regioni). Infine, i webGIS tengono conto delle esigenze di una ricerca di tipo multidisciplinare (archeologia, geomorfologia, rilievo fotogrammetrico o laser, ricerca storica, geofisica, ecc..) dando l’opportunità di integrare dati diversi e di eseguire analisi quantitative e spaziali altrimenti non realizzabili.
Lo sviluppo tecnologico, e una diversa concezione della visione geografica, ha inoltre consentito la realizzazione di soluzioni partecipative con la possibilità di integrare dati creati e suggeriti dagli utenti aumentando quindi il coinvolgimento da parte degli operatori di settore e dei cittadini. Le possibilità offerte da un approccio di questo tipo farebbero del webGIS archeologico “uno dei tasselli di
23 quella smart city informativa con cui sempre di più avremo a che fare nelle politiche di governance e gestione del territorio”37.
L’utilizzo della tecnologia webGIS, e GIS in generale, non è tuttavia esente da problematiche talvolta specifiche dell’ambito archeologico. La limitata disponibilità di risorse che solitamente interessa queste realizzazioni comporta innanzitutto la necessità di pianificare e garantire gli aggiornamenti alle banche dati per un periodo di tempo ragionevolmente lungo. Il ciclo di vita di questo tipo di applicazioni è infatti un argomento particolarmente delicato che può causare una rapida obsolescenza delle piattaforme causata dall’assenza di aggiornamenti dopo i primi rilasci e talvolta dalla frequente chiusura verso l’esterno, caratteristiche negative che portano ad obsolescenza e ad una veloce “morte contenutistica”38 .
Per quanto riguarda la tipologia e reperibilità dei dati archeologici, vale la pena accennare alla problematica dei ‘dati grezzi’, provenienti direttamente dalla documentazione di scavo, da cui possono essere derivati i dati di sintesi o ‘dati interpretati’.
In molti casi non si ha disponibilità, per mancata pubblicazione, dei risultati delle indagini e viceversa, a fronte di interpretazioni e sintesi ricostruttive pubblicate non vi è traccia negli archivi delle sovrintendenze dei dati di scavo39.
Questa problematica, strettamente connessa al tema dell’accessibilità e della proprietà intellettuale, comporta spesso la necessità di integrare dati di tipologia diversa, causando un sostanziale disallineamento dei contenuti archiviati nei geodatabase; inoltre, riguarda strettamente il tema degli Open Data, particolarmente delicato in ambito archeologico per la ricaduta sull’efficacia dell’attività di tutela del patrimonio archeologico e, di conseguenza, su un modello di pianificazione territoriale rispettoso dei resti sepolti40.
Da un punto di vista più tecnico, le problematiche di un GIS/webGIS archeologico sono nella maggior parte dei casi correlate alla tipologia stessa dei dati reperiti. Soprattutto in ambito urbano, si ha a che fare con una sovrapposizione stratificata delle informazioni georeferenziate che spesso vengono archiviate su un unico layer GIS data l’effettiva impossibilità di suddividere in layer distinti. Ci troviamo
37 NOTI 2012, p. 94 38 NOTI 2012, p. 93
39 ANICHINI, GATTIGLIA 2012, pp. 31-39 40 ANICHINI, GATTIGLIA 2012, pp. 31-39
24 di fronte a città in cui ovviamente si è costruito sugli stessi spazi e dove interventi e ritrovamenti relativi a epoche diverse sono totalmente o in parte sovrapposti. Gli edifici dell’ambiente urbano sono spesso interessati da cambiamenti nella destinazione d’uso e nella forma; una caratteristica sostanzialmente anomala in altre applicazioni GIS che comporta una certa difficoltà nel rappresentare visivamente i dati e nella loro gestione. Concretamente, l’interrogazione simultanea di oggetti grafici sovrapposti disposti su un unico layer comporta una risposta multipla da parte del sistema che può essere complicato consultare e interpretare.
I GIS archeologici, soprattutto in ambito urbano, sono caratterizzati dalla necessità di inserire in un unico geodatabase dati multitemporali e multiscala provenienti da scavi e ritrovamenti relativi a diverse epoche storiche e desunti da fonti eterogenee per qualità e per modalità di acquisizione e precisione geografica.
Questa complicazione, di difficile soluzione, può essere affrontata solamente con la definizione di una robusta e scalabile architettura di database e di specifiche e scelte tecniche ben progettate e adeguate al contesto archeologico oggetto dello studio.
Infine, la comprensibile difficoltà di georeferenziazione dei dati archeologici può comportare una sostanziale incertezza nel posizionamento degli stessi. Tale incertezza, ovviamente non banale per una banca dati geografica, è stata affrontata in alcuni casi con l’utilizzo di tipologie grafiche diverse (puntuali o poligonali), in altri con la differenziazione a livello di database assegnando simbologie e colorazioni diverse in base al grado di qualità del posizionamento. Allo stato attuale, il numero dei webGIS archeologici sviluppati in Italia è fortemente limitato, in contrapposizione alle numerose esperienze presenti nel panorama internazionale.
Nonostante si assista, già da anni, ad un numero elevato di progetti finalizzati all’introduzione delle tecnologie più avanzate, soprattutto nell’ambito della fruizione dei beni culturali, possiamo elencare solamente tre esperienze recenti che hanno applicato un approccio multidisciplinare allo studio del patrimonio archeologico con la realizzazione di webGIS strutturati: Progetto MAPPA (Pisa), OpenCiTy (Catania), SITAR (Roma).
25 Tali progetti di archeologia urbana, illustrati nel prosieguo di questo capitolo, sono caratterizzati da forti peculiarità e da approcci sostanzialmente diversi ed hanno costituito importanti esperienze per la diffusione della conoscenza archeologica e per l’applicazione di best practices nei processi e nelle metodologie di raccolta, archiviazione, gestione e rappresentazione dei dati.
2.2 Progetto MAPPA
2.2.1. Descrizione del progetto
Il progetto MAPPA (Metodologie Applicate alla Predittività del Potenziale
Archeologico)41 nasce nel 2011 con l’obiettivo principale di realizzare una Carta
di Potenziale Archeologico di Pisa, una città pluristratificata in cui “i resti archeologici delle comunità che l’hanno abitata e i segni dei paesaggi (pollini, carboni, ossa animali, tracce di antiche paludi e campi coltivati, di corsi d’acqua e dune costiere) che l’hanno caratterizzata si nascondono nel suo sottosuolo e convivono con la città moderna”42.
Realizzato dall’Università di Pisa43 con un finanziamento della Regione Toscana
(PAR-FAS 201044) e la collaborazione del Comune di Pisa, della Direzione
Regionale per i Beni Culturali e Paesaggistici della Toscana e delle Soprintendenze per i Beni Archeologici della Toscana e per i Beni Architettonici, Paesaggistici, Artistici, Storici ed Etnoantropologici delle province di Pisa e Livorno, ha sviluppato il suo lavoro principalmente nel periodo 2011-2013 sotto la direzione della Prof.ssa Maria Letizia Gualandi.
Il progetto si è rivelato sin dall’inizio molto ambizioso per la portata innovativa degli obiettivi preposti e poi raggiunti:
• la definizione di un algoritmo matematico in grado di calcolare il potenziale archeologico della città;
• la realizzazione della Carta di Potenziale Archeologico dell’area urbana e periurbana di Pisa;
• la realizzazione del webGIS;
41 http://www.mappaproject.org/ 42 GUALANDI 2012, p. 15
43 Dipartimenti di Civiltà e forme del sapere, di Matematica e di Scienze della Terra
44 PAR FAS, linea di azione 1.1.a.3, ambito disciplinare Scienze e tecnologie per la salvaguardia e la valorizzazione dei beni culturali.
26 • lo sviluppo del primo archivio open data dell’archeologia italiana (MOD,
Mappa Open Data archive).
La Carta di potenziale archeologico è stata realizzata dal gruppo di lavoro utilizzando informazioni molto diversificate, integrando quelle di tipo storico-archeologico con dati provenienti da indagini e prospezioni geologiche e geofisiche, ricostruzioni geomorfologiche, cartografie e catasti storici, dati toponomastici, analisi delle componenti di edilizia urbana.
Tutti i dati sopra indicati hanno consentito, attraverso l’applicazione dell’algoritmo di potenziale, di definire un grado di probabilità di trovare resti archeologici in zone per le quali non sono disponibili informazioni. Negli scopi del gruppo di lavoro, la Carta di Potenziale Archeologico rappresenta uno strumento innovativo di predizione che supera la classica Carta Archeologica, fondamentale per consultare aree interessate da scavi e documenti di vario genere, ma non utilizzabile in situazioni prive di queste informazioni. L’elaborato costituisce inoltre un importante strumento di pianificazione territoriale che consente di accrescere la conoscenza del patrimonio archeologico e può essere utilizzato all’interno dei piani di governo del territorio delle pubbliche amministrazioni con l’obiettivo di fornire un protocollo standardizzato, un insieme di linee guida reiterabili in altri contesti caratterizzati da centri storici pluristratificati con dati di partenza molto eterogenei45.
Il Progetto MAPPA non si è limitato alla realizzazione della Carta di Potenziale Archeologico dell’area urbana di Pisa, ma si è spinto oltre ponendo anche un altro obiettivo, rivoluzionario per il mondo dell’archeologia italiana: la realizzazione del MOD46 (MAPPA Open Data archaeological archive), il primo
archivio italiano di dati archeologici open. Il MOD ha come obiettivo quello rendere facilmente accessibili le informazioni e i documenti delle indagini archeologiche, molto spesso totalmente o parzialmente non pubblicati e di difficile consultazione.
Realizzato sotto forma di web application scritta in PHP con database MySQL (Fig. 2.1), contiene attualmente 119 archivi, principalmente dell’area urbana di Pisa ma riferiti anche ad altre zone del territorio nazionale. Per ogni archivio, l’utente ha la possibilità di scaricare le relazioni di scavo e i relativi dataset
45 GUALANDI 2012, pp. 15-21
27 (schede, rilievi, fotografie, immagini, testi, file georeferenziati, ecc.) che costituiscono la documentazione “grezza” dello scavo stesso.
Fig. 2.1 – Interfaccia dell’applicazione MOD (Mappa Open Data)
Parallelamente alla pubblicazione del MOD, sono stati inoltre approfonditi gli aspetti legali relativi alla privacy e alla paternità intellettuale dei dati accessibili dalla piattaforma, cercando di fare chiarezza in una legislazione particolarmente caotica47. Tutti gli autori degli archivi pubblicati sul MOD sono tutelati a livello di
diritto d’autore dal codice DOI (Digital Object Identifier)48 riconosciuto a livello
internazionale e di immediata visibilità sulla rete Internet.
A questo proposito è importante citare il sondaggio “Open data e l’archeologia italiana”, promosso sul sito del progetto, che ha visto un grande successo di partecipanti e dal quale è emersa chiaramente l’esigenza dell’apertura e del libero accesso all’informazione archeologica, temi molto dibattuti negli anni recenti anche grazie al lavoro svolto dal Progetto MAPPA49.
47 ANICHINI, CIURCINA, NOTI 2013, pp. 133-159 48 http://www.medra.org/it/
28
2.2.2. La carica innovativa del Progetto MAPPA
Il Progetto MAPPA ha avuto un ruolo fondamentale nel panorama italiano dell’informazione archeologica. La carica innovativa, il raggiungimento di obiettivi ambiziosi, l’utilizzo delle nuove tecnologie hanno favorito un modo di pensare alternativo e fortemente orientato alla condivisione e accessibilità del dato. Sin dall’inizio dei lavori, MAPPA si è contraddistinto per l’utilizzo intensivo del sito web e dei canali social con lo scopo dichiarato di farsi conoscere da un’utenza altrimenti impossibile da raggiungere sensibilizzando l’opinione pubblica sui temi dell’archeologia urbana, dell’Open Data e dell’Open Access. E’ importante inoltre evidenziare la notevole produzione scientifica del gruppo di lavoro con l’uscita di due volumi e raccolte di articoli (MapPapers) disponibili in download sul sito del progetto oltre alle pubblicazioni su riviste nazionali e internazionali. Infine, l’organizzazione di convegni annuali nella sede di Pisa, in cui sono stati invitati importanti relatori, sono state le occasioni per discutere delle tematiche del progetto con ricercatori e operatori del settore.
Come accennato in precedenza, tra i prodotti realizzati dal gruppo di lavoro, va innanzitutto citato il primo esempio italiano di modello matematico di potenziale archeologico50, progettato con lo scopo di rendere possibile la reiterazione e
l’affinamento del calcolo in zone diverse facilitando così l’applicazione del modello stesso nell’ambito della pianificazione e della tutela.
L’algoritmo matematico, pensato per lavorare su specifiche tipologie di dati, archeologici e geomorfologici, ricrea le regole che determinano il manifestarsi di un fenomeno. In particolare, i fenomeni indagati sono gli elementi che compongono il tessuto urbano e periurbano: case, chiese, strade, necropoli, manifatture, ma anche orti, giardini, campi coltivati, fiumi, acquitrini ecc. La definizione dell’algoritmo è basata sulla individuazione di “relazioni” fra i tipi di manufatti archeologici e le informazioni paleogeografiche, relazioni che sono state analizzate implementando una versione modificata dell’algoritmo PageRank51 partendo dall’assunto che i criteri utilizzati per l’attribuzione del
potenziale archeologico siano molto simili a quelli adoperati dai motori di ricerca
50 DUBBINI 2013, pp. 101-113 51 LANGVILLE, MEYER 2006
29 per l’assegnazione di importanza alle pagine web, in quanto entrambi fondati sulle relazioni reciproche52.
Il MOD e la pubblicazione dei dati geografici sulla piattaforma webGIS, hanno enormemente esteso la platea scientifica e pubblica, aumentando la diffusione della conoscenza e rendendo accessibile il dato archeologico e l’informazione relativa al suo posizionamento geografico.
L’approccio open e l’utilizzo di licenze aperte di tipo CC-BY53 ha consentito di far
circolare una grande quantità di dati grezzi e di prospettare una soluzione che, partendo dal basso, coinvolga l’intera comunità archeologica modificando abitudini e definendo linee guida e standard. Tutto questo in un quadro sicuramente complicato e diffidente da parte di molti studiosi del settore spesso orientati a proteggere e nascondere gelosamente i propri dati.
Ulteriore elemento di innovazione del progetto è stato l’approccio metodologico multidisciplinare. Sono infatti rari, nel panorama italiano, i casi in cui le tematiche connesse al patrimonio archeologico sepolto, soprattutto in ambito urbano, vedono operare insieme archeologi, geologi e matematici.
Lo studio di predittività effettuato per produrre la Carta del Potenziale Archeologico richiede infatti un approfondito lavoro in sinergia tra le varie figure scientifiche. In particolare, la collaborazione tra archeologi e geologi applicata ad un’ampia area metropolitana è di fatto una novità assoluta nel panorama italiano, soprattutto in un’area di pianura con dislivelli modesti per la quale è stata necessaria un’approfondita analisi geomorfologica attraverso immagini LIDAR, indagini geofisiche, l’interpretazione di dati sul tracciato dei paleoalvei e quindi sul deflusso naturale delle acque e le scelte insediative del passato54.
L’utilizzo delle discipline matematiche, inoltre, ha avuto sin dall’inizio l’obiettivo di rendere quanto meno soggettiva possibile la definizione del modello in modo da garantire la possibilità di esportazione della metodologia in altri contesti.
52 DUBBINI 2013, pp. 101-113 53 http://www.creativecommons.it/
30
2.2.3. La struttura dati
La struttura geoinformatica del Progetto MAPPA, progettata e realizzata direttamente dal gruppo di lavoro composto da archeologi, geologi e matematici, è basata su una suddivisione in differenti dataset archiviati all’interno di un RDBMS (Relational Database Management System) con componente spaziale (GeoDatabase).
Risulta evidente la notevole eterogeneità di dati all’interno della piattaforma GIS: dati di sottosuolo (stratigrafie, pozzi, penetrometrie) e di superficie (microrilievo, rete idrografica attuale, geomorfologia), dati archeologici (interventi e ritrovamenti, elevati, tracce aerofotogrammetriche, ecc.), dati urbani (edifici, strade, sottoservizi, ecc.), ortofoto di diverse epoche, DTM (Digital Terrain Model) e DSM (Digital Surface Model) ad alta risoluzione, piani quotati diversi per ogni epoca storica.
In particolare, sono stati generati i seguenti dataset principali55:
• Archeologia del sottosuolo • Archeologia degli elevati
• Tracce leggibili da fotointerpretazione aerea • Geoarcheologia • Sedimentologica/stratigrafia • Geomorfologia e paleogeografia • Idrografia • Topografia attuale • Cartografia storica
L’architettura informatica è basata su una struttura relazionale con tabelle collegate tra loro, contenenti sia dati sia thesauri utilizzati come riferimento per la standardizzazione delle terminologie e di altre informazioni quali i periodi temporali.
Questa struttura permette di gestire e organizzare le informazioni provenienti dai diversi ambiti disciplinari e consente la generazione di differenti livelli informativi. Tra questi riveste certamente un’importanza fondamentale il livello informativo archeologico che ha il compito di descrivere in maniera più oggettiva possibile la realtà archeologica archiviando (sia spazialmente che a livello di attributi) i dati di
31 archeologia del sepolto, archeologia degli elevati e lettura archeologica delle tracce da fotointerpretazione aerea.
La struttura logico concettuale di MAPPA è basata sulla “dicotomia tra oggettivo e interpretato, tra dato e informazione più banalmente, in ambito archeologico, tra archeografia e archeologia56”. Il livello informativo archeologico rappresenta
quindi, per il gruppo di lavoro, un insieme strutturato di informazioni che vanno al di là della semplice archiviazione dei ritrovamenti. Questi ultimi vengono infatti associati e rielaborati assieme agli altri livelli informativi (es. paleo-ambientali, fonti storiche, ecc.) in modo da permettere una ricostruzione interpretativa flessibile e in continuo movimento rendendo il livello stesso uno strumento professionale e di ricerca57.
All’interno del dataset dell’archeologia sepolta è stato individuato l’intervento archeologico come unità minima di riferimento con posizionamento geografico riconoscibile, definito come “singola attività archeologica di qualunque tipologia per unità spaziale continua (ad es. un unico lavoro che dia luogo a differenti e non contigui saggi di scavo viene diviso in tanti interventi quanti sono i saggi)”58.
In generale, l’intervento archeologico comprende qualsiasi informazione appartenente all’archeologia del sepolto59, indipendentemente dalla fonte di
provenienza e non sottoposta a interpretazione: un recupero occasionale ed uno scavo stratigrafico sono quindi trattati all’interno della stessa struttura di archiviazione. L’utilizzo dell’intervento come tassello fondamentale della struttura di database ha permesso di sintetizzare uniformemente le informazioni e consentito di risolvere il problema dell’eterogeneità delle fonti che sono qui trattate in modo paritetico.
Nell’ambito del singolo intervento, il grado informativo è esplicitato dall’Unità Stratigrafica, composta da schede e quantificazione dei materiali, che permette di definire e rendere evidente la qualità e la quantità dell’intervento stesso. All’interno della struttura di database gli interventi sono stati descritti nella rispettiva tabella (Fig. 2.2) attraverso dati topografici e tecnici (es. parametri per
56 ANICHINI, GATTIGLIA 2012, p.34 57 ANICHINI, GATTIGLIA 2012, pp. 31-39 58 ANICHINI, GATTIGLIA 2012, p.36
59 Da notare che l’archeologia degli elevati è stata di fatto separata da quella sepolta sia a causa del numero
sostanzialmente basso dei relativi interventi sia con lo scopo dichiarato di riconoscere una specificità alla disciplina.
32 la collocazione topografica, tipologia e modalità di effettuazione, nomi degli esecutori e dei responsabili scientifici), dati “cronologici” (suddivisione in preistoria, età protostorica, età etrusca, età romana, età tardo antica, alto medioevo, basso medioevo, età moderna, età contemporanea), dati sul materiale documentario disponibile, fonti di informazione primaria (archivistiche o bibliografiche), dati redazionali (autore, data, ecc..).
La tabella degli interventi è inoltre collegata a sottotabelle correlate che archiviano informazioni quali georeferenziazione, descrizione, collocazioni, bibliografia, riferimento documentario.
Fig. 2.2 – Scheda della tabella “Interventi” (da Fabiani, Gattiglia, 2012, p.52)
Una delle problematiche più importanti riguarda sicuramente la precisione del posizionamento spaziale degli interventi, un’informazione molto eterogenea e spesso desumibile con difficoltà dalle fonti. La scelta fatta è stata quella di indicare un livello di precisione associato agli elementi grafici differenziando a livello di database due classi (“preciso” e “non preciso”) e fornendo quindi all’utente un’informazione fondamentale sul grado di affidabilità geografica (Fig. 2.3).
33
Fig. 2.3 – Ubicazione degli interventi archeologici suddivisi in base all’affidabilità del posizionamento geografico: in rosso “Preciso”, in arancione “Non Preciso”.
Tra le altre problematiche riscontrate, citiamo la difformità tra i riferimenti cronologici disponibili nelle fonti, affrontata sia utilizzando un inquadramento cronologico molto ampio (dalla preistoria all’età contemporanea), sia inserendo le datazioni iniziali e finali assolute. In particolare, i secoli sono stati datati con inizio nell’anno 1 e con fine nel successivo anno 100 in modo da agevolare le interrogazioni numeriche da parte degli utenti. La cronologia numerica è stata affiancata da una versione testuale con suddivisione nei macro periodi citati in precedenza.
Per quanto riguarda l’archeologia degli elevati, ogni edificio rilevato è stato inserito in una tabella definita UAU (Unità Architettonica Urbana) che contiene, tra gli altri dati, quelli relativi all’attuale funzione e alla cronologia iniziale e finale, collegata alle tabelle CA (Complesso Architettonico) e CF (Corpo di Fabbrica) entrambe in relazione con le schede dei prospetti e delle fasi degli elevati.
34 Infine, il database archeologico contiene anche la documentazione di scavo con tabelle riguardanti i dati stratigrafici (US/USM), reperti e riferimenti interpretativi60.
2.2.4. La piattaforma GIS
I dati del Sistema Informativo Geografico del Progetto MAPPA, opportunamente definito AIS (Archaeological Information System) dal gruppo di lavoro61 sono stati
archiviati all’interno di un geodatabase con Sistema di Riferimento Roma 40 Gauss-Boaga (EPSG: 3003) che prevede i seguenti componenti principali:
• Archeologia (livello informativo archeologico) • Geologia e geomorfologia
• Città storica
• Città contemporanea • Ambiente
Per quanto riguarda la base cartografica, sono state utilizzate le Carte Tecniche Regionali (CTR) di Regione Toscana in scala 1:2000 e 1:10.000 nei formati raster e vettoriali e la cartografia catastale con sistema nativo Cassini-Soldner (emanazione Siena) riproiettati su Roma 40.
Non è negli scopi di questo lavoro di tesi la descrizione dettagliata della complessa struttura di geodatabase utilizzato. Riteniamo tuttavia utile descrivere brevemente quella del livello informativo archeologico, suddiviso in 3 dataset fondamentali: Sottosuolo, Elevati, Tracce.
Analogamente al SITAR62, è stata utilizzata la tipologia grafica poligonale per la
rappresentazione degli elementi archeologici, in particolare per quella degli interventi, evitando quindi il ricorso alla classica simbologia puntuale eccetto che per la rappresentazione dei toponimi. Questa scelta ha semplificato la rappresentazione delle emergenze archeologiche che acquisiscono quindi una ben definita consistenza materiale, eliminando la necessità di differenziare con primitive diverse ed utilizzando solo una distinzione a livello di attributi, diminuendo quindi il processo interpretativo per gli utenti. Come accennato in
60 FABIANI, GATTIGLIA 2012, pp. 41-71 61 ANICHINI, GATTIGLIA 2012, pp. 31-39 62 CAMPANA 2011, pp. 41-45
35 precedenza, è stata effettuata una suddivisione in base al grado di precisione del posizionamento spaziale con due classi (“preciso” e “non preciso”)63.
L’archeologia del sottosuolo comprende cinque tipologie di elementi grafici poligonali (interventi, US, caratterizzazioni, UT, strutture). Gli interventi rappresentano gli oggetti poligonali più importanti del livello informativo archeologico e descrivono le aree interessate da indagini archeologiche nel sottosuolo di qualsiasi tipo e qualità. Ogni intervento rappresenta di fatto un contenitore all’interno del quale sono presenti i ritrovamenti e costituisce un riferimento nella georeferenziazione delle piante di scavo o di UT64.
Nei casi di bassa qualità della georefenziazione gli interventi sono considerati non localizzabili con precisione all’interno di un determinato areale e possiedono quindi una georefenziazione approssimativa.
Il dataset degli Elevati comprende elementi sia poligonali (UAU, CA, CF) che lineare (fasi)65.
Infine il dataset vettoriale delle tracce comprende i risultati della ricerca delle anomalie da fotointerpretazione ed è definito dai poligoni delle tracce individuate nella loro reale consistenza e da un layer lineare di sintesi. Per l’interpretazione delle tracce sono stati utilizzati fotogrammi georeferenziati acquisiti in un intervallo temporale dal 1943 al 2010.
Per quanto riguarda la componente geomorfologica, vale la pena accennare alla realizzazione delle carte paleogeografiche di periodo che sono state ricostruite con analisi geostatistica attraverso interpolazione di dati provenienti dagli scavi e dagli studi geoarcheologici. Il risultato dei processi interpolativi, esperienza pressoché unica nel panorama dell’archeologia urbana in Italia, è stata la definizione dei DTM (Digital Terrain Model) relativi ai diversi periodi storici. La differenza tra i vari DTM ha consentito il calcolo della volumetria dei depositi e della crescita media di elevazione del terreno nei vari periodi66.
63 ANICHINI, GATTIGLIA 2012, pp. 31-39 64 ANICHINI, GATTIGLIA 2012, pp. 31-39
65 Le fasi sono rappresentate da un grafo lineare sia perché rappresentano il risultato di un processo
interpretativo sia perché non è possibile fisicamente attribuire loro uno spessore (cit. FABIANI, GATTIGLIA 2012, p.62)
36
2.2.5. II webGIS del Progetto Mappa
Il webGIS è stato scelto come strumento principale per la pubblicazione e la libera consultazione sul web dei dati archeologici, geologici e geomorfologici relativi all’area urbana di Pisa.
Realizzato con strumenti totalmente Open Source, prevede un’architettura informatica67 costituita da:
٠ Un web server Apache
٠ Un webGIS Application Server (MapServer)
٠ Un framework front-end (p.mapper) di MapServer.
L’interfaccia web è basata su p.mapper, una soluzione client di MapServer descritta nel Capitolo 1, che utilizza il modulo PHP/Mapscript per rendere disponibili classi e funzioni MapServer in ambiente PHP. Il geodatabase è in formato PostGIS/PostgreSQL, un database relazionale ampiamente utilizzato nell’informatica geografica.
Il webGIS è caratterizzato da elevata usabilità e semplicità di utilizzo con numerose funzionalità tipiche dei sistemi di web mapping: strumenti di navigazione, pulsanti di interrogazione puntuale o areale, gestione dei layer con possibilità di eseguire gli zoom sull’estensione complessiva di ogni livello, gestione delle trasparenze, esportazione dei risultati, possibilità di inserimento di punti di interesse, possibilità di stampa di layout in formato PDF.
Programmato con utilizzo di AJAX per evitare la necessità di refresh della pagina in seguito all’utilizzo degli strumenti di navigazione, è stato progettato per essere utilizzato in prima analisi senza necessità di particolari conoscenze informatiche e con la possibilità di accedere a tematismi “preconfezionati” ad uso di utenti non esperti del settore. La possibilità di eseguire ricerche molto articolate garantisce comunque un utilizzo efficace anche per utenti più esperti.
L’interfaccia grafica (Fig 2.4) è costituita da una barra verticale sulla sinistra, dell’elenco layer sulla destra e della mappa centrale oltre ad una barra orizzontale in cui sono presenti alcune funzioni di supporto (stampa in formato PDF, link, esportazione immagine in formato PNG o geoTIFF georeferenziato, manuale di uso, disclaimer, crediti, collaborazione attiva).
67 NOTI, 2012, pp. 87-95
37 In particolare, il comando “link” permette di memorizzare l’indirizzo per ricreare la medesima visualizzazione (layer visibili e coordinate della zona inquadrata) in modo da poterla inviare ad altri utenti.
Fig. 2.4 – Interfaccia del webGIS MAPPA
Gli strumenti “Collabora” e “Segnala” introducono nell’applicazione un importante carattere partecipativo attraverso il quale l’utente può prendere parte all’aggiornamento del webGIS. Il primo consente di segnalare errori sul layer degli interventi sia per quanto riguarda gli attributi sia per la georeferenziazione. L’utente ha infatti la possibilità di scaricare un template in formato ESRI Shapefile che permette di georeferenziare l’area dell’intervento con database strutturato da riempire. In questo modo un utente specializzato potrà inviare al gruppo di ricerca un layer GIS riempito da sottoporre prima della pubblicazione. Il pulsante “Segnala”, rivolto a cittadini non specializzati, permette attraverso un form di segnalare la presenza di scavi eseguiti senza la sorveglianza di archeologi. Le segnalazioni ricevute saranno poi inoltrate direttamente alla Soprintendenza per i Beni Archeologici della Toscana.
All’apertura del webGIS (Fig. 2.4) la mappa è scalata sull’area di indagine con visualizzazione immediata del limite dell’area di studio, degli interventi tematizzati in base alla precisione di posizionamento e di alcuni tematismi attuali (rete idrografica, edificato, reti di trasporti).
La barra verticale permette di utilizzare gli strumenti di navigazione (zoom, pan), di recuperare informazioni sugli oggetti dei vari layer, selezionare più oggetti attraverso selezione rettangolare, effettuare misure di area e distanza, posizionare punti di interesse e modificare le trasparenze.
38 I layer GIS presenti nella legenda sono organizzati in gruppi e possono essere resi visibili o meno attraverso checkbox, con la possibilità di zoomare sull’estensione complessiva del layer. L’utente ha inoltre la possibilità di modificare la scala di visualizzazione dall’apposita casella a discesa o inserendo un valore di scala a piacimento.
Il webGIS è costituito dai seguenti livelli informativi archiviati, per la parte vettoriale, in formato PostGIS:
• Carta di Potenziale o Gradi potenziale o Potenziale Totale
• Interventi Archeologici (archeologia del sepolto) o Interventi o Ritrovamenti o Elementi archeologici o Sepolture o Area di studio • Tracce aerofotografiche • Analisi degli elevati
o Unità di riferimento
o Unità di riferimento per cronologia o Fasi edilizie
o Unità con foto periodizzate • Cartografia storica
o Vari layer di cartografia dal 1544 al 1817 • Geomorfologia o Carotaggi e georadar o Carta geomorfologica • Paleogeografiche o Vari DTM di periodo • Vincolo Archeologico
• Modello Digitale del Terreno
o DTM e shaded relief attuali derivati da rilievo LIDAR 2008 con risoluzione 1 m
