CAPITOLATO TECNICO PER LA PROGETTAZIONE, LA REALIZZAZIONE E LA MESSA IN PRODUZIONE DEL SISTEMA INFORMATICO PER LA GESTIONE E LA FRUIZIONE DEL

Transcript

1 CAPITOLATO TECNICO PER LA PROGETTAZIONE, LA REALIZZAZIONE E LA MESSA IN PRODUZIONE DEL SISTEMA INFORMATICO PER LA GESTIONE E LA FRUIZIONE DEL DATABASE TOPOGRAFICO REGIONALE LOTTO 1 Salvato il: mercoledì 11 novembre

2 Premessa ART. 1 PREMESSE E OBIETTIVI Cenni sul contesto di riferimento... 5 ART. 2 OGGETTO DELLA GARA... 7 ART. 3 DESCRIZIONE DELLE ATTIVITÀ Prodotti e servizi Prerequisiti tecnologici Progetto esecutivo Contenuti Modalità di redazione Articolazione, tempistica e collaudi Realizzazione di Prototipi Valutazione ed approvazione del progetto esecutivo Realizzazione e messa in produzione del Sistema Modalità di realizzazione Documentazione e manualistica Installazione in area di test e collaudo applicativo Collaudo finale del sistema, tuning e messa in produzione Formazione Tempistica complessiva Periodo di garanzia ART. 4 FUNZIONALITÀ DEL SISTEMA Allegati tecnici Documenti di riferimento ART. 5 CASI D USO E REQUISITI Scenario generale I casi d uso di riferimento Aggiornamento Fruizione Le aree funzionali del sistema Il DBMS georelazionale Architettura funzionale per l aggiornamento

3 5.6 Aggiornamento tramite Anagrafe Comunale degli Immobili Architettura funzionale per la fruizione Primo caricamento dei dati ART. 6 INFRASTRUTTURA DATI TERRITORIALI Il Repository Manager Integrazioni tra Sistema DBTR e Repository Moka CMS (Content Management System) GIS Integrazione tra Sistema DBTR e architettura MOKA SIGMA TER Integrazione tra Sistema DBTR e DBTI di Sigmater Il progetto ELISA e l Anagrafe degli Immobili Integrazione tra Sistema DBTR e l Anagrafe Comunale degli Immobili Sistema Pubblico di Connettività ART. 7 OBBLIGHI E REQUISITI DI SICUREZZA Sicurezza, privacy e riservatezza Designazione quale responsabile esterno del trattamento di dati personali Controllo degli accessi... Errore. Il segnalibro non è definito. 7.4 Accessibilità ART. 8 MODALITÀ DI PRESENTAZIONE DELL OFFERTA Offerta tecnica Offerta economica ART. 9 AMMONTARE E DURATA DEL CONTRATTO Importo complessivo Durata del contratto ART. 10 SERVIZI COMPLEMENTARI ART. 11 MODALITÀ DI PRESTAZIONE DEI SERVIZI ART. 12 MODALITÀ DI PAGAMENTO ART. 13 VERIFICHE E CONTROLLI SULLO SVOLGIMENTO DEL SERVIZIO ART. 14 PENALITÀ ART. 15 INVARIABILITÀ DEI PREZZI ART. 16 CAUZIONE DEFINITIVA

4 ART. 17 SUBAPPALTO ART. 18 PROPRIETÀ DEI PRODOTTI ART. 19 BREVETTI E DIRITTI D AUTORE ART. 20 RISOLUZIONE DEL CONTRATTO ART. 21 RECESSO ART. 22 RESPONSABILITÀ ED OBBLIGHI ART. 23 PRETESE DI TERZI ART. 24 CONTROVERSIE ART. 25 SPESE CONTRATTUALI ART. 26 OSSERVANZA DI LEGGI, REGOLAMENTI E NORME

5 Art. 1 Premesse e obiettivi 1.1Cenni sul contesto di riferimento La Regione Emilia-Romagna, da tempo promuove azioni rivolte alla costituzione di un insieme comune di dati territoriali e di applicazioni, tali da costituire una infrastruttura relativa ai dati territoriali che consenta di condividere in modo formale dati e servizi applicativi tra i soggetti preposti all analisi e gestione del territorio. Nucleo portante di tale infrastruttura è il database topografico, che organizza i contenuti tipici di una cartografia topografica tecnica alle grandi scale (geometrie, georeferenziazione, attributi) integrati con i reticoli stradali, con altri strati vettoriali fondamentali e con ulteriori informazioni territoriali di interesse generale, secondo le specifiche di contenuto definite dall Intesa Stato Regioni Enti Locali 2004 e successive. I contenuti che sono organizzati secondo logiche di sistema informativo geografico moderno, seguono regole di qualità definite e sono descritti tramite metainformazione secondo gli standard ISO/TC211; in tal senso risultano più facilmente aggiornabili, maggiormente fruibili e di qualità garantita. Il Data Base Topografico, così strutturato, rappresenta quindi la moderna organizzazione delle Carte Tecniche Regionali (CTR) e costituisce il nucleo portante del sistema informativo geografico a supporto delle attività di pianificazione e di gestione del territorio. Le attività di produzione del DBT attualmente in corso porteranno all istituzione di un Data Base Topografico su ciascuna unità di fornitura, corrispondente territorialmente ad un comune oppure ad una aggregazione di Comuni adiacenti. Al fine di permettere una fruizione dei dati in esso contenuti nel continuo territoriale, essenziale per la costruzione di servizi basati su di essi ed erogati dalla Regione, occorre superare i limiti imposti dalle 5

6 unità di fornitura e realizzare un unico database centralizzato, fondendo i singoli database derivanti dalle unità di fornitura. Tale database, il Database Topografico Regionale, dovrà poi essere integrato nell Infrastruttura Regionale dei dati geografici allo scopo di consentirne un utilizzo ed una fruizione congiunta ed omogenea con gli altri dati presenti, nelle modalità organizzative e tecnologiche più opportune. Inoltre poiché è fondamentale che la base di riferimento, per mantenere il suo ruolo strategico, abbia contenuti aggiornati ed adeguati a rappresentare tempestivamente l evoluzione del territorio, sono di fondamentale importanza le modalità tecniche ed organizzative con le quali tale database verrà gestito, posto che, per la natura stessa dei suoi contenuti e gli attori che concorrono agli aggiornamenti, la gestione risulta di particolare complessità. Per quanto sopra descritto, allo scopo di rendere il Database Topografico Regionale lo strumento strategico gestibile e fruibile secondo le modalità tecniche ed organizzative più adeguate, si determina l esigenza di costituire un sistema informatico adeguato a tali scopi. 6

7 Art. 2 Oggetto della gara La presente gara ha per oggetto la fornitura di servizi di analisi, progettazione esecutiva e realizzazione del sistema che andrà a costituire l infrastruttura tecnologica necessaria per la costituzione del Database Topografico Regionale centralizzato e nel continuo territoriale, per la gestione nel tempo recependo gli aggiornamenti anche da parte degli Enti Locali, secondo modalità condivise, sulla base di flussi di dati concordati e di qualità adeguata e certificati, e per la fruizione a tutti i livelli della P.A. dei suoi contenuti tramite una serie di servizi e funzioni integrati nel contesto tecnologico dell infrastruttura geografica regionale condividendo modelli, dati e tecnologie sia con quanto già realizzato in ambito regionale che con i progetti analoghi attualmente in corso e che prevedono l accesso a dati ufficiali e condivisi. Dovranno quindi essere definiti nel dettaglio flussi informativi, modalità di interscambio e cooperazione, modalità di utilizzo dei dati, i relativi servizi e le componenti tecnologiche che il sistema dovrà realizzare per gestire e rendere fruibile, trattando varie tipologie di utenza, il DBTR implementato, definendo il modello fisico dei dati, su piattaforme tecnologiche adeguate alla realizzazione efficiente e sicura delle operazioni previste.. Dovranno inoltre essere individuate ed attuate le attività necessarie alla messa in opera del sistema complessivo, ivi comprese le azioni per il primo caricamento dei dati, ottenendo il continuo territoriale, a partire dalle singole unità di fornitura disponibili. 7

8 Art. 3 Descrizione delle attività 3.1Prodotti e servizi I prodotti e servizi oggetto della fornitura comprendono quindi: Redazione del progetto esecutivo: o analisi dei requisiti ed analisi funzionale modellazione dei dati o redazione delle relative documentazioni o sviluppo di eventuali prototipi o sequenza logica e tempistica delle fasi di sviluppo Impianto del DBMS e primo caricamento dei dati Realizzazione e sviluppo delle applicazioni, dei servizi e delle relative componenti Installazione dei DB, delle componenti e delle applicazioni presso le infrastrutture regionali. Test e collaudo delle applicazioni e delle componenti del sistema Formazione assistenza e supporto ai tecnici regionali Messa in produzione del sistema Garanzia estesa e 3.2Prerequisiti tecnologici Il sistema sarà installato sulle infrastrutture informatiche regionali e devono per tanto essere seguite le linee guida per la governance del sistema informatico regionale, che prevedono le filiere supportate per applicazioni e siti web basate su architetture a tre livelli (web server, application server, database server). Le filiere sono le seguenti: filiera A: applicazioni basate su tecnologia JAVA filiera B: applicazioni basate su tecnologia Microsoft filiera C: applicazioni basate su tecnologia OpenSource 8

9 Di seguito gli stack tecnologici per le tre filiere: Piattaforma Microsoft (Windows 2003) Piattaforma Linux (Linux RedHat AS 5) FILIERA A Applicazioni su tecnologia JAVA (specifiche J2EE) WS: Microsoft IIS 6 AS: IBM WebSphere 6.1 (JDK 1.5) DB: Oracle 10g ( ) WS: Apache 2 AS: JBoss DB: PostgreSQL 8.3 Oracle 10g ( ) FILIERA B Applicazioni su tecnologia Microsoft FILIERA C Applicazioni su tecnologia OpenSource (framework LAMP) WS: Microsoft IIS 6 AS: Microsoft.NET (Framework 2.0 o 3.5) DB: SQL Server WS: Apache 2 AS: PHP, Python, Perl, Tomcat 6.0 DB: MySQL 5 PostgreSQL 8.3 Legenda: WS: Web Server AS: Application Server DB: Database Server La scelta dello stack tecnologico ed i fabbisogni di massima dovranno essere indicati nell offerta tecnica, mentre l analisi di dettaglio, nell ambito di tale stack, sarà definita nel progetto esecutivo. Ogni altra componente, middleware o altre componenti di terze parti, dovrà essere parte della fornitura ivi compreso le relative licenze. Per ciò che riguarda le tecnologie relative ai sistemi geografici, risulta preferibile l adozione di tecnologie compatibili con quelle già adottate nei sistemi e nelle applicazioni che costituiscono l infrastruttura geografica della Regione, i cui sistemi e componenti sono comunque disponibili nel caso in cui possano proficuamente essere riusati nello sviluppo del sistema in oggetto. 9

10 3.3Progetto esecutivo Il progetto esecutivo dovrà essere descritto attraverso la opportuna documentazione, redatta, avendo quali presupposti fondamentali, quanto segue e quanto riportato negli allegati, che costituiscono parte integrante del presente capitolato tecnico Contenuti In riferimento all analisi dei requisiti, il documento deve contenere l'elencazione formale e relativa descrizione di tutti i requisiti dell'applicazione, siano essi funzionali che qualitativi, emersi nella fase di definizione delle esigenze utente. I prodotti e servizi richiesti dalla presente gara sono descritti nel dettaglio dalle sezioni seguenti. In particolare, il Progetto Esecutivo deve contenere: Definizione del contesto attuale e dei casi d uso Descrizione delle esigenze Vincoli Requisiti di sicurezza Numero e tipologia degli utenti coinvolti Dati e servizi trattati, in forma di schema concettuale Indicazioni generali della soluzione, sia in termini funzionali che architetturali Matrice ruoli/funzionalità Riferimenti ad ulteriore documentazione di interesse prodotta o preesistente. Riguardo l analisi funzionale il documento definisce totalmente l'applicazione in modo da ottenerne una descrizione logico/operativa completa e non ambigua. In particolare conterrà in modo completo ed esaustivo l analisi del sistema relativamente a: disegno complessivo e di ogni componente del sistema 10

11 descrizione dei processi e dei flussi informativi, delle modalità di interscambio e cooperazione descrizione della logica applicativa per ogni componente e per ogni funzionalità individuata disegno dei modelli dati, logici e fisici, relativi ai database e ai flussi informativi di interscambio. disegno delle interfacce applicative e delle interfacce utente analisi delle attività necessarie al primo caricamento dei dati aspetti non funzionali (architettura, sicurezza, vincoli, prestazioni, ecc.) individuazione e pianificazione dei test da effettuare e dei metodi di misurazione per le varie componenti. documentazione relativa ad ogni aspetto relativo all analisi. Saranno inoltre esplicitate: Descrizione dell architettura generale del sistema, dei relativi fabbisogni e prerequisiti tecnologici per l installazione delle varie componenti. Descrizione del sistema di sicurezza da implementare a fronte di un'analisi dei rischi ed in ossequio alla normativa regionale vigente Individuazione delle metodologie e dei parametri di efficienza del sistema complessivo e delle varie componenti, ivi compresi gli scenari ipotizzati, i carichi di lavoro, gli accessi concorrenti e i risultati attesi. Collegamenti con sistemi già implementati e relative criticità Modalità di redazione Il progetto esecutivo sarà redatto in stretta collaborazione con la Regione Emilia-Romagna, costituendo uno specifico team di 11

12 progetto, mettendo in atto tutte le necessarie azioni di collaborazione con altri soggetti su indicazione della stessa Articolazione, tempistica e collaudi Il progetto esecutivo dovrà comprendere l articolazione delle singole attività di sviluppo, delle relative tempistiche, dei prodotti intermedi, dei collaudi e approvazioni in corso d opera, della consegna dei prodotti, delle documentazioni e dei collaudi finali. Il progetto esecutivo comprenderà quindi la necessaria documentazione, anche tramite opportuni schemi e diagrammi, che esplicita tali aspetti. Nel progetto esecutivo dovranno essere indicate anche le modalità con cui effettuare i collaudi intermedi e finali di ogni singola componente e del sistema complessivo. 3.4Realizzazione di Prototipi Allo scopo di meglio comprendere i contenuti del progetto esecutivo è richiesta la realizzazione di uno o più prototipi relativi alle varie componenti o aree funzionali, del sistema in oggetto. 3.5Valutazione ed approvazione del progetto esecutivo Il progetto esecutivo dovrà essere approvato dalla Regione in seguito a valutazione prima di procedere alla realizzazione del sistema. La valutazione comprenderà e riguarderà anche la documentazione relativa al progetto esecutivo stesso ed i prototipi realizzati. 3.6Realizzazione e messa in produzione del Sistema Modalità di realizzazione L articolazione e la tempistica dello sviluppo, ivi compresi i collaudi in corso d opera sui prodotti intermedi, dovranno seguire 12

13 quanto stabilito nel progetto esecutivo, salvo diverse valutazioni in accordo con la direzione lavori Documentazione e manualistica Nella realizzazione del sistema è compresa la redazione di documentazione connessa alle attività oggetto della fornitura. In particolare dovrà essere prodotta documentazione relativa a: a)componenti applicative sviluppate (documentazione tecnica del codice) b)manuale di istallazione e gestione: è lo strumento necessario alle strutture preposte all installazione ed esercizio dell applicazione. È un manuale rivolto a personale tecnico e deve contenere tutte le informazioni necessarie per installare, configurare e gestire l'applicazione. Possono essere indicati eventuali requisiti particolari di gestione del backup/restore dei dati, se diversi dalle politiche definite sui server c)manuale utente: il documento deve fornire una descrizione generale dell applicazione e una guida operativa all utilizzo delle singole funzionalità disponibili Installazione in area di test e collaudo applicativo Nelle attività previste sono comprese tutte le attività necessarie all installazione, e relativa verifica, di tutte le componenti del sistema presso le strutture preposte della Regione Emilia-Romagna. Le strutture saranno individuate dalla direzione lavori sulla base dei fabbisogni e prerequisiti tecnologici definiti nel progetto esecutivo. Tutti i prodotti consegnati dovranno essere sottoposti a collaudo secondo le articolazioni e le modalità stabilite dal Progetto Esecutivo. Per ciò che riguarda le componenti da installarsi presso i soggetti locali, saranno individuati dalla direzione lavori una serie di soggetti quali prototipi per l installazione. 13

14 Inoltre il sistema sarà sottoposto a collaudo da parte dei servizi preposti della Regione, per ciò che è previsto nelle linee guida per governance del sistema informatico regionale. Il sistema potrà essere installato sui sistemi di produzione solamente in seguito all esito positivo di tali collaudi Collaudo finale del sistema, tuning e messa in produzione Tutte le applicazioni, i servizi e le componenti installate nei server di produzione, dovranno essere sottoposte a collaudo relativamente alla operatività complessiva in produzione secondo quanto stabilito nel progetto esecutivo relativamente agli scenari ipotizzati, carichi di lavoro, accessi concorrenti degli utenti e risultati attesi. Dovranno essere eventualmente effettuate tutte le operazioni di tuning complessivo relativamente ai DBMS, alle singole componenti e al sistema complessivo. Il sistema sarà considerato in produzione solo in caso di esito positivo del collaudo finale. 3.7Formazione Dovranno essere previste le seguenti attività formative opportunamente strutturate ed articolate in piani formativi a vari livelli, a seconda dell interazione che i vari soggetti avranno con il Sistema: Formazione assistenza e supporto ai tecnici regionali che svolgeranno il ruolo di gestori del sistema, in funzione degli specifici ruoli quali amministratori del sistema, amministratori dei contenuti, amministratori degli utenti, ecc.. Formazione agli utenti nell utilizzo del PG, in funzione delle tipologie di utenti previsti e delle modalità di utilizzo del sistema (utenti non esperti / utenti esperti, modalità di interfacciamento, ecc..). 14

15 3.8Tempistica complessiva Tutte attività andranno in ogni caso completate nei tempi indicati dall amministrazione appaltante in conformità a quanto previsto dall Art. 11 Ammontare e durata del contratto. 3.9Periodo di garanzia E richiesto un periodo di garanzia di 36 mesi a partire dalla data del collaudo finale. 15

16 Art. 4 Funzionalità del Sistema Il Sistema in oggetto è descritto in modo dettagliato negli allegati 1.1, 1.2, 1.3, e 1.6, che ne illustrano il progetto di massima, architettura generale e le principali aree funzionali. 4.1Allegati tecnici In particolare gli allegati illustrano: Allegato n. 1.1: Inquadramento ed architettura generale Il documento inquadra lo scopo generale del sistema, la sua collocazione nell ambito della Regione Emilia-Romagna e la sua collocazione nell ambito della CN-ER. Vengono individuate le principali classi di servizi e funzionalità che il sistema renderà disponibili e quali saranno le principali classi di utenti. Allegato n. 1.2: Il DBMS georelazionale di riferimento Il documento descrive gli aspetti funzionali relativi al DBMS che implementa il Database Topografico di riferimento: descrizione in relazione all architettura, contenuti e modello dati di riferimento, modalità di aggiornamento e gestione delle transazioni, vincoli e controlli di qualità, modalità di storicizzazione dei contenuti, modalità di gestione della metainformazione, modalità di accesso ai dati, classi di utenti, Definizione di Identificatori Univoci (UID). Allegato n. 1.3: Il Sistema di gestione Il documento inquadra le funzionalità richieste dal sistema in merito alle azioni di aggiornamento dei contenuti, ai formati dati relativi ai dataset di aggiornamento, ai relativi processi di autorizzazione, controllo di qualità e validazione, nonché alla loro memorizzazione temporanea in qualità di proposta di aggiornamento. Il documento descrive le esigenze e le funzionalità necessarie per semplificare, pur mantenendo gli standard di qualità desiderati, le azioni di 16

17 controllo, validazione e di aggiornamento delle proposte relative alle classi ritenute prioritarie. Allegato n. 1.4: Il Sistema di aggiornamento da Anagrafe Comunale degli Immobili Il documento inquadra le funzionalità richieste per il sottosistema di composizione ed invio delle proposte di aggiornamento del DBTR, operate a partire dalle istanze di aggiornamento delle Anagrafi Comunali degli Immobili presenti presso gli Enti Locali o i rispettivi CS. Allegato n. 1.5: Il Sistema di fruizione Il documento inquadra le funzionalità richieste ed i prerequisiti per il sottosistema di fruizione dei dati. Vengono analizzate le principali esigenze di fruizione in relazione alle diverse modalità di utilizzazione dei contenuti del Database Topografico e alle diverse tecnologie. Allegato n. 1.6: L infrastruttura dati territoriali della Regione Il documento illustra le principali caratteristiche delle infrastrutture geografiche presenti in Regione, con le quali il sistema in oggetto dovrà integrarsi, ed i principali riferimenti alle normative tecniche nazionali ed internazionali in merito ai dati geografici, cui il sistema dovrà riferirsi. 4.2Documenti di riferimento I Documenti di riferimento per il presente capitolato sono resi disponibili sul sito Emilia-Romagna Digitale all indirizzo: In particolare, è resa disponibile la documentazione relativa al Database Topografico regionale: 17

18 Regione Emilia-Romagna: Database Topografico Regionale contenuto e struttura concettuale, v.5.1 Regione Emilia-Romagna: Database Topografico Regionale Allegato integrativo di contenuto e struttura concettuale, v. 5.1 Regione Emilia-Romagna: Database Topografico Regionale Modello Logico per l implementazione del database Topografico, v 6.3 Regione Emilia-Romagna: Database Topografico Regionale La Qualità requisiti e Modalità di certificazione., v. 6.3 Regione Emilia-Romagna: Dizionario dati, v. 6.3 Regione Emilia-Romagna: Data Base Topografico alle grandi scale formato di trasferimento e sua struttura fisica e la successiva specifica di Integrazione dei dati per la resa grafica, v. 6.3 Regione Emilia-Romagna: Data Base Topografico alle grandi scale Applicazione dei requisiti di qualità sul Formato di scambio, v. 6.3 Regione Emilia-Romagna: Database Topografico regionale: Il trattamento della metainformazione ; Regione Emilia-Romagna: Capitolato tecnico per la realizzazione del lotto del DB Topografico regionale in modalita C Regione Emilia-Romagna: Capitolato tecnico per la realizzazione dell aggiornamento 2008 del DB dell Uso del Suolo e del completamento ed aggiornamento del DB Topografico Regionale Alcuni prodotti relativi al Database Topograrfico: Formato di scambio, File DWG di plottaggio, Formato ESRI GeoDB e modello ESRI ArcGIS 9.2/9.3 di fruizione Sono resi disponibili inoltre documentazioni realtivi a: Anagrafe Comunale degli Immobili Infrastruttura Geografica regionale 18

19 o Moka o Repository regionale o Catalogo Metadati o Smart Web Mapping Infrastruttura e Servizi o ICAR - SPCoop Altri riferimenti sono costituiti dai seguenti: Regione Emilia-Romagna: Accordo attuativo della convenzione costitutiva della COMMUNITY NETWORK EMILIA-ROMAGNA per la gestione condivisa dei Servizi SIGMA TER, del Data Base Topografico Regionale dell ANAGRAFE COMUNALE degli IMMOBILI (ACI) e dell ANAGRAFE COMUNALE dei SOGGETTI, degli OGGETTI e delle RELAZIONI (ACSOR), del monitoraggio dell attività edilizia e del controllo dell abusivismo, degli strumenti informatici per la pianificazione urbanistica comunale (PSC, POC e RUE). I relativi documenti sono disponibili sul sito di riferimento indicato sopra CNIPA: Regolamento recante regole tecniche per la definizione del contenuto del Repertorio nazionale dei dati territoriali, nonché delle modalità di prima costituzione e di aggiornamento dello stesso, pubblicato sul sito del CNIPA all'indirizzo: IT/Attivit%C3%A0/Sistemi_Informativi_Territoriali/ Specifiche_tecniche/Regolamento_Repertorio/ Nel seguito vengono introdotte le principali funzionalità ed i requisiti di progetto. 19

20 Art. 5 Casi d uso e requisiti 5.1Scenario generale Lo scenario in cui si colloca il sistema prevede il Database Topografico Regionale (DBTR) centrale quale DB operazionale sul quale verranno recepite le azioni di aggiornamento; un area funzionale nella quale vengono gestiti, organizzati e validati gli atti di aggiornamento che, se validati, verranno recepiti nel DBTR; un area funzionale ove verranno predisposti i dati e messi in atto i servizi per la fruizione dei dati. I casi d uso sotto riportati esemplificano azioni di gestione e di fruizione. 5.2I casi d uso di riferimento Allo scopo di analizzare nel dettaglio sia le funzionalità per la gestione degli aggiornamenti che le funzionalità per la fruizione dei dati, vengono individuati alcuni casi d uso di riferimento per lo sviluppo delle funzionalità richieste Aggiornamento Tralasciando qui gli aspetti autorizzativi, vengono indicate nel seguito le modalità previste di istituzione di un flusso di aggiornamento da parte di varie tipologie di Soggetti Caso1: aggiornamento massivo da ortofoto E il caso di aggiornamenti periodici realizzati sia per verifica generale dei contenuti, sia per una eventuale nuova realizzazione in seguito, ad esempio, alla disponibilità di nuove orto immagini. In questa modalità potranno eventualmente essere raccolti altri contenuti proposti da soggetti autorizzati al fine di produrre un lotto di aggiornamento complessivo su di una data zona. Queste azioni sono svolte da soggetti che operano in nome e per conto della Regione e sono 20

21 quindi da considerarsi come una azione Interna al sistema di gestione. Caso2: aggiornamento prodotto da soggetti locali titolari per conto della Regione della gestione del database topografico E il caso di aggiornamento ad opera di soggetti titolari dell aggiornamento su di un territorio di competenza ad esempio un Comune che producono un lotto comprendente un contenuto che può essere completo o anche parziale, purchè documentato, del database topografico relativo al territorio di competenza. E il caso, ma non solo, dei Comuni che hanno adottato il modello database topografico per il proprio SIT. Tali soggetti potranno produrre dati in un formato di scambio concordato che quindi dovrà rispettare tutte le regole di qualità previste per il DBTR. Caso 3: aggiornamento prodotto da soggetti locali di particolari componenti informative sulla base di accordi intercorsi con Regione E il caso in cui soggetti autorizzati, interni o esterni alla regione, producano dati utilizzabili al fine di aggiornare il contenuto del DBTR. L esempio è quello dei dati relativi ad un nuovo edificio, derivati da processi amministrativi, oppure relativi alla costruzione di una nuova opera idrica da parte di un ente di bonifica. I dati di aggiornamento dovranno essere organizzati secondo un modello definito e condiviso ed anche le modalità di costruzione del dato di aggiornamento dovranno seguire regole definite. Fanno parte di questa modalità anche gli aggiornamenti che derivano da processi informatizzati che trattino dati relativi al territorio come ad esempio i processi finalizzati al trattamento delle Anagrafi Comunali degli Immobili. Caso 4: segnalazioni per l aggiornamento 21

22 Non ultimo caso legato all aggiornamento del database è la gestione di segnalazioni sul grado di aggiornamento o di correttezza dei contenuti in generale, da parte di soggetti che fruiscono dei dati e siano titolati alla segnalazione. Le segnalazioni potranno essere poi processate da parte di chi è titolare dell aggiornamento (casi 1 e 2) Fruizione Caso1: consultazione della cartografia derivata o di suoi livelli informativi Viene richiesto l accesso alla nuova Carta Tecnica a scala 1:5000 o di suoi livelli informativi secondo la classica categorizzazione dei contenuti della cartografia tecnica, eventualmente sulla base dei tagli cartografici standard Caso2: replica di componenti informative del DBT in vari formati fisici quali DWG, DXF, SHAPE Componenti informative organizzate in insiemi auto consistenti possono essere estratte dal DBTR; ad esempio l insieme di viabilità ed edificato di una data porzione di territorio Caso3: fruizione di prodotti in ambito pubblico (Portale cartografico) Andranno analizzate in dettaglio le modalità con cui i sistemi di pubblicazione massiva dei dati, in primis il Portale cartografico della Regione, attualmente in fase di progetto, ma anche le altre applicazioni accessibili al pubblico (es.:map & Bookshop, Sentieri Web)potranno pubblicare il DBTR. Inoltre andranno analizzate nel dettaglio anche modalità di esposizione di servizi cartografici, quali WMS e WFS, in funzione delle tipologie di utente. Ciò premesso nel sistema andranno sviluppati i meccanismi tecnici con cui rendere fruibili i dati secondo tali modalità e soprattutto proporre standard elevati di qualità del servizio. 22

23 Nel seguito vengono riassunti i requisiti minimi funzionali generali: R1.1.1 Il contenuto del DBT prodotto su tutto il territorio regionale secondo le modalità di cui ai documenti di riferimento [10] e [11] deve essere memorizzato in un apposito DBMS geografico centralizzato a livello regionale, a costituire il DBT Regionale (DBTR) R1.1.2 Deve essere implementato un modello di aggiornamento di tipo distribuito che consenta di effettuare gli aggiornamenti del contenuto del DBTR con varie modalità, tali da garantire nel tempo una rappresentazione del territorio regionale di adeguata attendibilità sia spaziale che temporale. R1.1.3 Devono essere definiti i processi per la gestione degli aggiornamenti definendo soggetti coinvolti, ruoli, modelli dati, flussi e interfacce, relativi al sottosistema per la gestione. R1.1.4 Devono essere implementate adeguate modalità di fruizione del contenuto del DBTR che consentano di utilizzare tutti i prodotti e sottoprodotti derivabili dal DBTR R1.1.5 Devono essere definite e implementate sia le funzionalità e le tecnologie adeguate a rendere fruibili i dati contenuti nel DBTR che le modalità di integrazione nei processi applicativi che ne abbisognano. R1.1.6 Devono essere supportate politiche di gestione del DBTR sia per il suo aggiornamento che per la sua fruizione; tali politiche di gestione potranno variare nel tempo, ma questo dovrà comportare modesti interventi alla piattaforma applicativa di gestione e fruizione (facilità di arricchimento funzionale del sistema) R1.1.7 Nella progettazione e nello sviluppo del sistema dovrà essere fatto riferimento ai progetti attinenti e/o correlati, quali SigmaTer ed Elisa, per le Anagrafi 23

24 Comunali degli Immobili, là dove esistano aree di correlazione. R1.1.8 Nella progettazione e nello sviluppo del sistema dovrà essere fatto riferimento ai sistemi e alle infrastrutture, e relative tecnologie, sviluppate dalla Regione quali ad esempio il Repository dei dati geografici, il Metadata Manager, il sistema Moka e MokaKit R1.1.9 Devono essere gestiti profili di utenza differenziati e articolati R Deve essere garantita l integrità e deve essere supportato l accesso sicuro al DBTR 5.3Le aree funzionali del sistema Di seguito vengono brevemente descritti i tre sottosistemi che sono illustrati più in dettaglio negli allegati indicati, e sui quali verranno sviluppate in seguito sia analisi dei requisiti sia l analisi funzionale. Le aree riguardano: Il sottosistema di gestione del Database geografico che contiene il database topografico propriamente detto e tutte le informazioni accessorie che derivano dall analisi e dal progetto di dettaglio successivo. Il sottosistema relativo all aggiornamento e alle modalità di cooperazione con i soggetti titolati. Il sottosistema relativo alla fruizione dei dati del database topografico regionale e delle informazioni accessorie. 5.4Il DBMS georelazionale Allo scopo di disporre dei dati con la massima qualità intrinseca e con le necessarie garanzie di sicurezza, i dati dovranno essere gestiti all interno di un opportuno DBMS di tipo geografico 24

25 (GDBMS) che integri le componenti alfanumeriche e le componenti spaziali, ma anche tutte le informazioni accessorie derivate dagli atti di aggiornamento, dalla metainformazione ai dati storicizzati. La base dati rappresentata è univoca dal punto di vista del continuo territoriale tra unità di fornitura, lotti di aggiornamenti ed entità amministrative, e realizza quindi il database topografico regionale esteso all intero territorio. Il modello logico fisico dei dati deriva dal modello logico del database topografico regionale, esteso opportunamente per ciò che necessita per realizzare le funzionalità previste nel sistema. I requisiti minimi relativi al DBMS georelazionale possono essere così riassunti: R1.2.1 La struttura fisica del DBMS deve essere coerente con la definizione del modello logico e ottimizzare l uso dei meccanismi offerti dalla piattaforma tecnologica su cui verrà trasposto il modello logico, sulla base delle caratteristiche funzionali e delle esigenze del sistema di gestione R1.2.2 Il DBMS di riferimento deve preservare le caratteristiche di integrità referenziale e di consistenza topologica secondo quanto definito nel modello logico e nelle specifiche di qualità, definite nelle specifiche tecniche presenti tra i documenti di riferimento. R1.2.3 Devono essere previste le strutture dati ed i meccanismi necessari per la gestione della storicità dei contenuti del DBTR R1.2.4 Devono essere previste le strutture dati necessarie per la gestione dei metadati di istanza e di qualificazione dei dati di aggiornamento per ogni transazione di aggiornamento eseguita R1.2.5 Devono essere comparati i meccanismi di accesso previsti dai due sistemi, quello di gestione e quello di fruizione, per definire eventuali esigenze di repliche e 25

26 riorganizzazioni dei dati nel sistema di fruizione rispetto a quello di gestione, che viceversa ha come riferimento unico il modello logico specificato in Documento di rif.[4] 5.5Architettura funzionale per l aggiornamento L architettura funzionale necessaria per supportare i processi di aggiornamento, che si realizzano con modalità a volte profondamente differenziate e per opera di soggetti eterogenei, si fonda su alcuni concetti fondamentali: Viene definito e materializzato un DBT a livello regionale Vengono disaccoppiati in due momenti distinti l acquisizione dei dati di aggiornamento e l aggiornamento operato sul DBT regionale in modo da consentire di applicare tutte le politiche ritenute più adeguate sia di certificazione dello stato e della qualità sia di sincronizzazione tra aggiornamenti che riguardano lo stesso territorio operati da soggetti differenti Una volta realizzato l aggiornamento del DBT regionale questo viene notificato agli utenti che avevano procurato la proposta di aggiornamento Le modalità organizzative di dettaglio vengono approfondite nell allegato 1.3. I requisiti minimi per il sottosistema di aggiornamento possono essere così riassunti: R1.3.1 Il sistema di gestione opera in coerenza con quanto descritto nel documento di architettura generale del sistema ed ha come riferimento il DBMS georelazionale descritto sopra. R1.3.2 Deve essere implementato un modello di aggiornamento di 26

27 tipo distribuito. R1.3.3 Devono essere definiti Ruoli, Flussi e Processi che modificano il DBTR, attraverso proposte di aggiornamento e la loro approvazione. R1.3.4 Le proposte di aggiornamento devono essere organizzate in un Repository che ne mantenga nel tempo la traccia R1.3.5 Devono essere esposti servizi che supportino la redazione delle Proposte di aggiornamento a livello locale. R1.3.6 Il sistema deve consentire, quando possibile e nei limiti dei necessari controlli e validazioni da parte del Gestore, il trattamento automatico delle proposte di aggiornamento. In particolare ciò deve riguardare i casi indicati nel Allegato 1.1. R1.3.7 Il Sistema deve prevedere, nell ambito dei processi di validazione e aggiornamento, adeguate comunicazioni verso i soggetti proponenti riguardo non congruenze o approvazioni. R1.3.8 Oltre alle proposte di aggiornamento il sistema deve implementare un sistema di gestione di segnalazioni ad opera di soggetti registrati segnalazione della presenza di anomalie relative al DBTR consolidato. Le segnalazioni dovranno essere depositate in uno specifico Repository. R1.3.9 Le proposte di aggiornamento non trattabili automaticamente e le segnalazioni presenti nei rispettivi Repository, dovranno essere rese disponibili sia ai back office locali che operano per la costruzione di proposte di aggiornamento su zone interessate, coincidenti o limitrofe, sia al Backoffice Regionale che effettuerà le attività di aggiornamento ordinario e straordinario e di costruzione di dataset di aggiornamento. 27

28 5.6Aggiornamento tramite Anagrafe Comunale degli Immobili Come caso particolare dell aggiornamento ad opera di soggetti locali, devono essere previste tutte le funzionalità necessarie ad intercettare gli atti di variazione della Base dati relative alle Anagrafi Comunali degli Immobili nello standard Elisa, e a generare Proposte di Aggiornamento per il DBTR. Le funzionalità che andranno a comporre i requisiti del sottosistema che permette di realizzare quanto sopra descritto sono illustrate nell Allegato 1.4 che è parte integrante del presente capitolato. Di seguito si riportano i requisiti minimi principali: R1.4.1 Il sistema deve colloquiare con i servizi dell ACI e potersi attivare ad ogni sua variazione che possa interessare il DBTR. R1.4.2 Il sistema deve permettere di mantenere le relazioni fra variazioni dell ACI e le corrispondenti proposte di aggiornamento al DBTR. R1.4.3 Il sistema deve essere in grado di valutare la qualità dei dati dell ACI di interesse per il DBTR rispetto ai requisiti previsti per le proposte di aggiornamento. R1.4.4 Il sistema, verificata la qualità dei dati (R3), deve supportare la composizione della Proposta di Aggiornamento, nelle operazioni necessarie sia ti tipo geometrico che alfanumerico. R1.4.5 Nei casi ove non sia possibile redigere una Proposta, il sistema deve supportare la composizione di una Segnalazione che rifletta comunque la variazione ACI R1.4.6 Il sistema deve consentire di mantenere traccia dell esito delle validazioni dei dati e delle proposte di aggiornamento per poter mantenere i legami fra le entità dell ACI ed i corrispondenti oggetti nel DBTR v. R2 R1.4.7 Il sistema deve supportare la composizione della 28

29 metainformazione prevista dal DBTR, sia per ciò che riguarda la metainformazione di prodotto (relativo all aggiornamento) che la metainformazione di istanza relativa ai singoli oggetti. R1.4.8 Il sistema deve rendere disponibili ai gestori delle ACI degli Enti Locali opportuni strumenti a supporto della gestione delle Entità dell ACI di interesse per il DBTR, avvalendosi anche di dati geografici di supporto, allo scopo di operare gli inquadramenti nel territorio corretti rispetto al DBTR, ovvero alla base comune di riferimento R1.4.9 Devono essere realizzate le componenti funzionali che permettano di interfacciarsi con i servizi esposti da RER nell ambito dei sistemi di gestione e fruizione del DBTR, come i servizi di validazione, di invio di Proposte, accesso al DBTR. R I servizi di cui al requisito R9 (di colloquio con i servizi RER) dovranno essere sviluppati in modo tale da poter essere riutilizzati anche per proposte di aggiornamento al DBTR non derivanti dall ACI R Le proposte di aggiornamento al DBTR dovranno essere inoltrate in regione secondo il paradigma della cooperazione applicativa definito dal Codice dell Amministrazione Digitale (PDD, busta di e-gov, ) Il sistema si rivolge quindi a quegli Enti Locali che gestiscono, in forma singola o associata, la propria ACI. Le entità che interessano le proposte di aggiornamento e che possono derivare da aggiornamenti dell ACI sono di fatto i livelli minimi relativi al contenuto della Proposta di Aggiornamento così come descritti nell Allegato A dell Accordo attuativo della Convenzione costitutiva della Community Network Emilia-Romagna (DOC. RIF. [12]). 29

30 5.7Architettura funzionale per la fruizione Il DBT Regionale verrà reso fruibile, come illustrato nella schematizzazione della figura successiva, tramite la pubblicazione dei contenuti con servizi conformi agli standard adottati dalla Regione Emilia-Romagna. La fruizione si avvarrà dell infrastruttura di rete regionale e del Portale Geografico della Regione; è prevista la gestione distinta tra utenti generici (accesso internet) ed utenti accreditati (accesso intranet/extranet), così come di utenti con diverso grado di esperienza. Possono essere individuate alcune modalità, a titolo esemplificativo, che saranno oggetto di analisi nel corso del progetto esecutivo: pubblicazione della carta tecnica partendo dal contenuto del DBT, sul continuo territoriale: o con rappresentazioni differenziate dello stesso contenuto, oltre a quello della tradizionale CT5 b/n. Eventuali funzioni integrative accesso ed esportazione (tramite WFS) di strati vettoriali derivati dal DBTR: o come Layer SDE o shape file o in livelli DXF o in un formato di scambio evoluto (GML) I requisiti minimi per il sottosistema di fruizione possono essere così riassunti: R1.5.1 Il sistema di fruizione si deve basare su un DB ottimizzato per le interrogazioni R1.5.2 L allineamento del DB di fruizione al DB operazionale deve essere automatizzato e deve ridurre al minimo i 30

31 tempi di non disponibilità del DB R1.5.3 Sul DB di fruizione devono essere progettate viste orientate alla fruizione dei dati secondo differenti modalità e rappresentazioni cartografiche R1.5.4 Le viste sul DB di fruizione devono essere rese disponibili all esterno mediante servizi Web Map Services (WMS) e Tiled Map services (TMS). R1.5.5 Deve essere possibile accedere al DB di fruizione attraverso servizi Web Feature Service(WFS). R1.5.6 I Client Regionali dell infrastruttura GIS devono poter accedere al DB di fruizione attraverso i metadati applicativi del Repository Manager R1.5.7 Devono essere mantenute le correlazioni con gli elementi del DBTI SIGMA TER R1.5.8 Deve essere possibile, attraverso una procedura WEB, produrre Stampe complete (in formato PDF o equivalente) di singole tavole del DB di fruizione R1.5.9 Deve essere possibile, attraverso una procedura WEB, ottenere l estrazione di una porzione di territorio in formato DXF R Deve essere possibile, attraverso una procedura WEB, estrarre una porzione di territorio nel Formato di Scambio. (FS) 5.8Primo caricamento dei dati Come già indicato sopra, la Regione Emilia Romagna ha sviluppato il primo impianto del Database Topografico Regionale nella modalità denominata C, su circa 300 Comuni realizzati secondo le specifiche tecniche indicate nel capitolato (Doc. di riferimento [10]), inoltre ha in corso il completamento del primo impianto sui restanti Comuni e il contemporaneo aggiornamento del DBTR tramite ortofoto AGEA 2008 (doc di riferimento [11]). 31

32 Tale primo impianto è però disponibile nelle rispettive unità di fornitura, organizzate per Comuni Singoli o raggruppamenti di Comuni adiacenti, ciascuna organizzata come una base dati autonoma con strutture dati relative ai rispettivi capitolati di realizzazione, anche se sostanzialmente omogenee. Il Sistema di gestione e fruizione del DBTR in oggetto prevede che i dati siano disponibili e gestiti in una unica base dati strutturata secondo un modello aderente al modello logico del DBTR (v. doc. riferimento [4])organizzato nel continuo territoriale sull intero territorio dell Emilia-Romagna e rispondente alle regole di congruenza topologica e consistenza dei dati previste dalle specifiche tecniche del DBTR. Tra le attività oggetto della gara sono richieste l analisi tecnica e le successive attività di sviluppo necessarie al primo caricamento completo e rispondente ai requisiti previsti per la base dati. Andranno quindi risolte eventuali discrepanze tra i modelli dati delle unità di fornitura disponibili e la trasposizione nel modello fisico progettato per il DBTR in sede di progetto esecutivo. Tali unità di fornitura rispondono comunque a regole generali di consistenza tra unità adiacenti, riportate nelle specifiche di realizzazione del Database Topografico Regionale. 32

33 Art. 6 Infrastruttura dati territoriali Di seguito vengono brevemente illustrati i componenti principali dell infrastruttura geografica regionale nell ambito della quale devono essere contestualizzati gli interventi di progettazione ed attivazione dei sistemi per l aggiornamento e la fruizione del Database Topografico Regionale. L allegato 1.5 illustra in modo esaustivo l infrastruttura, gli aspetti tecnologici e le modalità di integrazione previste. 6.1Il Repository Manager Altrimenti definito come il catalogo dei metadati applicativi, tale componente consente di registrare in modo ordinato tutte le risorse cartografiche ed alfanumeriche disponibili in un'unica banca dati in modo che tutti gli utenti interni ed esterni alla regione e le applicazioni dell infrastruttura GIS possano avere un unico punto di accesso tramite il quale reperire le informazioni cercate o necessarie per assolvere un determinato compito. Il catalogo ha anche la funzione di conservare i Metadati applicativi che descrivono le caratteristiche delle banche dati di cui si dispone. In particolare il sistema prevede la possibilità di descrivere minuziosamente il dizionario dati e le relazioni esistenti fra le diverse entità; tutte le applicazioni che necessitano di cartografia si appoggiano ai metadati. È quindi possibile estendere in modo incrementale il repertorio, a fronte dell acquisizione di nuove cartografie o database alfanumerici, rendendo immediatamente disponibili le informazioni relative alla nuove banche dati e l accesso alle stesse a tutti gli utenti e alle applicazioni abilitate. Il Repository Manager è quindi strato informativo ed applicativo fondante dell infrastruttura GIS della regione Emilia-Romagna e 33

34 costituisce il contesto di riferimento sul quale sviluppare il sistema per la fruizione del database topografico Regionale Integrazioni tra Sistema DBTR e Repository L accesso applicativo al catalogo può avvenire tramite una serie di servlet appositamente predisposti nell infrastruttura e già utilizzati dai client regionali. Nel documento Documentazione sui servizi di catalogo per l accesso alle informazioni contenute nel Repertorio sono riportate le specifiche di utilizzo dei servizi. 6.2Moka CMS (Content Management System) GIS Il sistema Moka costituisce un ambiente software per generare applicazioni GIS utilizzando un insieme di oggetti precedentemente archiviati in un catalogo condiviso. In questo senso Moka rappresenta uno dei primissimi esempi a livello nazionale di CMS (Content Management System) GIS: utilizzando il sistema infatti anche un utente non sviluppatore può comporre la propria applicazione popolandola di dati, cartografie e funzioni estratte dal catalogo Moka. L applicazione così generata potrà essere resa accessibile ad una o più categorie di utenti: ci saranno pertanto applicazioni riservate ad un gruppo ristretto di utenti ed applicazioni disponibili a tutti i cittadini. Ogni applicazione può essere inoltre personalizzata sulla base del profilo dell utente che vi accede, in modo tale che ad un certo utente siano disponibili certe funzionalità (es.: editing interattivo della cartografia) che ad altri non sono consentite. Gli oggetti catalogati possono appartenere a diverse tipologie: in particolare è possibile catalogare sia dati che funzioni software. Quindi il catalogo Moka conterrà: cartografie, tematizzazioni e legende, banche dati, tabelle e relazioni, funzioni web, interfacce GIS ed applicazioni. 34

35 L attività di catalogazione è normalmente svolta dall amministratore del SIT (Sistema Informativo Territoriale)regionale avvalendosi di una componente di Moka denominata MokaKit. Il modulo MokaKit è stato realizzato con tecnologia web ed è pertanto accessibile (disponendo ovviamente delle necessarie autorizzazioni) in intranet agli utenti dei diversi servizi della Regione Emilia-Romagna ed in extranet agli enti locali del territorio regionale connessi mediante la rete regionale Lepida. MokaKit può essere utilizzato dalle categorie di utenti che si occupano dell amministrazione delle banche dati, da coloro che si occupano della pubblicazione e divulgazione dei dati, e da coloro che si occupano della preparazione di applicazioni GIS dotate di funzionalità specifiche e, ovviamente, dall amministratore stesso del sistema Moka Integrazione tra Sistema DBTR e architettura MOKA Le funzionalità legate al collaudo e alla validazione dei dati, previste nel Sistema DBTR, sono già disponibili in ambiente Moka in versioni sviluppate per il Primo Impianto del DBTR. Opportunamente Upgradate potranno essere impiegate nel Sistema DBTR. L ambiente Moka CMS può catalogare i dati, opportunamente organizzati e simbolizzati, contenuti nel DBTR allo scopo di: utilizzarli proficuamente all interno di applicativi Moka generare servizi applicativi e funzioni condivise nell ambiente Moka CMS generare servizi WMS e WFS per la fruizione di strati informativi del DBT opportunamente definiti. Tutte le applicazioni realizzate in ambiente Moka CMS sono costituite da componenti riusabili in altre applicazioni nel medesimo ambiente, dove possono essere catalogate ed impiegate funzionalità o web services esterni. 35

36 6.3SIGMA TER Il progetto SIGMA TER ha realizzato una infrastruttura per l integrazione e l interscambio di informazioni territoriali fra pubbliche amministrazioni. In particolare il focus sul quale si è posta maggior attenzione è quello relativo alla disponibilità per gli enti locali delle banche dati catastali aggiornate e certificate dall Agenzia del Territorio. La Regione Emilia-Romagna è stato ente sviluppatore, nonché capofila, nella prima fase di progetto che si è conclusa da oltre un anno. Oggi si sta procedendo alla messa in esercizio e al riuso nell ambito regionale delle componenti sviluppate Integrazione tra Sistema DBTR e DBTI di Sigmater Il DBTI di SIGMA TER conserva e aggiorna le informazioni catastali dell intera Regione Emilia-Romagna. Di interesse rispetto alla integrazione con Il Database Topografico regionale sono due tabelle: S3_CT48T_UIU_X_CIVICI nella quale vengono mantenute le correlazioni fra le unità immobiliari catastali e la numerazione civica esterna S3_CT50T_PART_X_CIVICI nella quale vengono mantenute le correlazioni fra le particelle terreni e la numerazione civica esterna Ogni altro legame fra Database Topografico Regionale e DBTI di SIGMA TER potrà derivare da relazioni di tipo topologico. 6.4Il progetto ELISA e l Anagrafe degli Immobili Nell ambito del Progetto Elisa ( la Regione Emilia-Romagna prevede di condividere con gli EELL della Regione Emilia-Romagna un modello di approccio e di intervento integrato sui temi del catasto, della fiscalità e della gestione del territorio. Il modello da condividere deve mirare alla gestione delle 36