PostgreSQL per la tutela
archeologica

Matteo Frassine - Soprintendenza Archeologica del Veneto

Giuseppe Naponiello - Arc-Team s.r.l.

Correva l'anno 2010

Come risolvere il problema dell'alfabetizzazione informatica richiesta dai GIS?

Come gestire dati eterogenei in relazione ai procedimenti amministrativi e al CAD
(D.Lgs. 82/2005 mod. D.Lgs. 235/2010 s.m.i.) ?

Dematerializzazione della P.A.
(Dlgs. 82/2005 mod. Dlgs. 235/2010 s.m.i.)

Archiviazione digitale delle pratiche
Riordino e digitalizzazione del materiale pregresso

________________Ricapitolando________________

  • Sistema di facile utilizzo
  • Operativo, calato nella realtà lavorativa quotidiana
  • Gestibile autonomamente anche in carenza di risorse umane e finanziarie
  • Georeferenziazione degli interventi sul territorio da web
  • Carta archeologica (policromia – presenza/assenza)
  • Ricerca potente per utenti interni ed esterni (archeologia preventiva)
  • Pianificazione degli interventi

La Soprintendenza Archeologia del Friuli-Venezia Giulia decide di finanziare lo sviluppo di un primo prototipo.

Viene scelta come area campione il territorio della Provincia di Pordenone

Gruppo di lavoro

  • Progettazione e direzione scientifica: Matteo Frassine (Soprintendenza Archeologia del Friuli-Venezia Giulia)
  • Sviluppo del sistema: Giuseppe Naponiello (Arc-Team s.r.l.)
  • Responsabile procedure amministrative e gestione archivi: Ambra Betic (Soprintendenza Archeologia del Friuli-Venezia Giulia)
  • Data entry: Daniele Girelli (Soprintendenza Archeologia del Friuli-Venezia Giulia)

"Just another database from PA!!!"

Fasti On Line

Catalogo Generale dei Beni Culturali

Istituto Centrale per il Catalogo e la Documentazione

Vincoli In Rete

SIGECWEB

SITAR

Tutti ottimi sistemi ma con caratteristiche diverse da quelle desiderate!

Ricerca

Archivi e

Pratiche per una

Tutela

Operativa

Regionale

Il primo prototipo

Hardware e Sistema operativo

  • CED DG-OR MIBACT - Area Ricerca, Innovazione Organizzazione
  • Server virtualizzato con Ubuntu 11.04
  • 2GB RAM, 20GB di spazio disco

Web Server

  • Apache + Tomcat7
  • Geoserver 2.2

DB Server

  • PostgreSQL 8.4
  • Postgis 1.5

Interfaccia

  • PHP + CSS
  • jQuery + OpenLayers

Analisi delle procedure amministrative

Macroclassi di oggetti

Pratiche

Comprendono progetti e interventi, vincoli, concessioni di scavo, perizie

Documenti

Comprendono documenti soggetti a protocollazione, documentazione tecnica relative ai progetti valutati, documentazione di scavo

Soggetti

La classe comprende sia gli utenti di sistema che tutti quei soggetti esterni che interagiscono con l'Amministrazione

Archivi

La classe raggruppa tutta la documentazione pregressa (cartacea e non)che va integrata nel nuovo sistema

Soggetti

Profilazione degli utenti

  • Amministratore sistema
  • Funzionario
  • Responsabile archivi
  • Responsabile vincoli
  • Responsabile depositi
  • Addetto stampa
  • Responsabile biblioteca
  • Archeologi referenti
  • Assistenti F3
  • Responsabile siti
  • Ufficio protocollo
  • Soprintendente
  • Tirocinante

Per ogni tipo di utente il sistema carica, al login, un ambiente di lavoro con funzioni e strumenti specifici per la tipologia di utente, oltre ad una bacheca personale all'interno della quale sono presenti statistiche e informazioni personali...una specie di "stato dell'arte" del proprio lavoro

Tipologia soggetti rubrica

  • Persone, liberi professionisti
  • Uffici MIBACT
  • Associazioni, fondazioni
  • Società, cooperative, studi professionali
  • Musei, Biblioteche, Istituti Culturali non statali
  • Enti religiosi
  • ASL
  • Enti pubblici (anche enti locali e territoriali)
  • Università, Scuole, centri di formazione/ricerca

Lista valori conforme al vocabolario utilizzato per il software di protocollazione ESPI, attualmente utilizzao da tutte le Soprintendenze d'Italia

E la parte geografica?

Dal generale al particolare

Ancora più dettagli: la scheda di sito

  • Sito inteso come "contenitore" di informazioni eterogenee
  • Ogni livello informativo è un tassello che concorre alla conoscenza del sito
  • i record di alcuni livelli informativi possono "parlare" di più siti

Tra il 2011 e il 2012 entrano a far parte del progetto anche le Soprintendenze di Lombardia e Veneto, diventando parte attiva e dando un importantissimo contributo allo sviluppo del sistema

Nel 2013 anche la Toscana decide di partecipare "con riserva".

Gruppo di lavoro

  • Progettazione e direzione scientifica: Matteo Frassine (Soprintendenza Archeologia del Friuli-Venezia Giulia)
  • Sviluppo del sistema: Giuseppe Naponiello (Arc-Team s.r.l.)
  • Responsabile procedure amministrative e gestione archivi: Ambra Betic (Soprintendenza Archeologia del Friuli-Venezia Giulia)
  • Data entry: Daniele Girelli (Soprintendenza Archeologia del Friuli-Venezia Giulia)
  • Progettazione e coordinamento locale: De Francesco Stefania (Soprintendenza Archeologia della Lombardia)
  • Progettazione e coordinamento locale: Asta Alessandro (Soprintendenza Archeologia del Veneto)

Dalla progettazione alla messa in produzione: il pericolo è il nostro mestiere!

Il progetto ha suscitato da subito molto interesse da parte sia dei funzionari che delle ditte archeologiche

Il coinvolgimento diretto degli archeologi ha dato un'ulteriore spinta allo sviluppo di RAPTOR
l'interazione con chi lavora direttamente "sul campo" è uno degli aspetti più importanti del sistema

Punti di forza del sistema

Funzionari e archeologi lavorano a stretto contatto

  • Creazione di linee guida per la consegna della documentazione di scavo
  • Uniformità e normalizzazione dei dati raccolti
  • Creazione di "standard" di lavoro: positiva ricaduta anche sull'aspetto economico

La divisione dei compiti ha permesso un notevole abbattimento dei tempi di risposta della PA

  • I dati di scavo sono aggiornati e subito disponibili
  • ...di conseguenza c'è un maggior controllo del territorio
  • Una banca dati "condivisa" velocizza il lavoro di ricerca dei dati (bibliografia, rubrica, pratiche, confronti con scavi simili...)

Migrazione e upgrade del sistema
un passo necessario

Hardware e Sistema operativo

  • CED DG-OR MIBACT - Area Ricerca, Innovazione Organizzazione
  • Server virtualizzato con Ubuntu 11.04 Debian8
  • 2GB 4GB RAM, 20GB 50GB di spazio disco
  • QNAP QTS 4.1.4 24TB

Web Server

  • Apache + Tomcat7 8
  • Geoserver 2.2 2.8

DB Server

  • PostgreSQL 8.4 9.4
  • Postgis 1.5 2.1

Fare un upgrade di postgresq dalla 8.4 alla 9.4 può essere "doloroso"...

...ma un cambio di versione di postgis lo è ancora di più!

Restore di un geodatabase in 3 semplici mosse

  1. pg_dump -h host -p 5432 -U utente -Fc --insert database | gzip > file.gz
  2. gunzip file.gz
  3. postgis_restore.pl file | psql newdb

Prepararsi all'inevitabile

Le Soprintendenze di Veneto e Lombardia hanno messo a disposizione altri 2 server virtuali con le stesse caratteristiche di quello attualmente in uso e sono stati acquistati altri 2 NAS rispettivamente da 48TB (Lombardia) e 40TB (Veneto)

Per motivi "logistici" e soprattutto di "performance", l'accesso pubblico sarà reindirizzato sul server della Lombardia

Sincronizzazione dei NAS per un backup programmato dei file

La nuova infrastruttura ha potenzialità
bisogna solo capire come sfruttarle al meglio

Le soluzioni possibili sono tante e la scelta della strategia migliore è un passo molto delicato

Qualunque sia la scelta più adatta, considerando le caratteristiche del sistema, deve essere presa sulla base di alcuni concetti fondamentali:
1. Sicurezza
2. Scalabilità
3. Affidabilità
4. Disponibilità

E per finire un po' di numeri

Utenti registrati: 131
Numero massimo login:72, il 2015-09-03
Media connessioni giornaliera:15
Pratiche inserite:596
Documenti registrati:2044
Interventi sul territorio:175
Siti archeologici:6807
Vincoli archeologici:346
File caricati:5739
https://www.raptor.beniculturali.it www.arc-team.com arc-team-open-research.blogspot.it

beppenapo[at]arc-team[dot].com

@beppenapo https://independent.academia.edu/GiuseppeNaponiello https://www.researchgate.net/profile/Giuseppe_Naponiello