ALLEGATO N. 1.3 IL SISTEMA DI GESTIONE

Transcript

1 CAPITOLATO TECNICO PER LA PROGETTAZIONE E LA REALIZZAZIONE DEL SISTEMA INFORMATICO PER LA GESTIONE E LA FRUIZIONE DEL DATABASE TOPOGRAFICO REGIONALE LOTTO 1 ALLEGATO N. 1.3 IL SISTEMA DI GESTIONE

2 CAPITOLATO SISTEMA PER LA GESTIONE E FRUIZIONE DEL DBTR SCOPO DEL DOCUMENTO 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 controllo, validazione e di aggiornamento del DBT Regionale con le proposte relative alle classi ritenute prioritarie. 2

3 ALLEGATO 1.3 ILSISTEMA DI GESTIONE Sommario SCOPO DEL DOCUMENTO...2 SOMMARIO...3 INTRODUZIONE...4 DEFINIZIONI E GLOSSARIO...6 REQUISITI DEL SISTEMA DI GESTIONE...9 IL PROCESSO DI GESTIONE DEGLI AGGIORNAMENTI Proposte di Aggiornamento Il Backoffice Locale Il Backoffice Regionale I Flussi delle Proposte Repository delle Proposte di Aggiornamento Repository delle Segnalazioni I controlli di qualità Valutazione della possibilità di inserimento automatico della Proposta Inserimento della Proposta nel DBTR SERVIZI E FUNZIONALITÀ ESPOSTI VERSO I BACKOFFICE LOCALI SERVIZI E FUNZIONALITÀ ESPOSTI VERSO IL BACKOFFICE REGIONALE SERVIZI E FUNZIONALITÀ ESPOSTI VERSO IL COLLAUDATORE RIFERIMENTI

4 CAPITOLATO SISTEMA PER LA GESTIONE E FRUIZIONE DEL DBTR Introduzione Il Sistema di aggiornamento del Database Topografico Regionale è l insieme delle funzionalità che consentono di operare gli aggiornamenti al DBTR, secondo modalità distribuite e ad opera di più soggetti coordinati da un Gestore del DBTR. Il Sistema in oggetto rappresenta un sottosistema dell architettura di gestione fruizione del DBTR, descritta complessivamente nei seguenti documenti: - [1]. Architettura generale - [2]. Il DBMS Georelazionale di riferimento - [3]. Il Sistema di Fruizione del Database Topografico - [5]. Il Modello logico del Database Topografico Le modalità con cui tramite i dati di aggiornamento vengono operati gli aggiornamenti del DBTR sono principalmente due: - Aggiornamenti inviati da parte di soggetti locali che, in collaborazione con la Regione, producono dati di aggiornamento relativi a tutte o solo alcune tipologie di contenuti, sul loro territorio di competenza; i soggetti locali agiranno in genere sulla scorta di propri processi gestionali in relazione alle classi di cui sono titolari, producendo in modo asincrono dati che andranno validati e confrontati opportunamente sia con il DBTR esistente che con eventuali altri aggiornamenti, per garantirne la consistenza e la congruenza secondo le specifiche tecniche. - Aggiornamenti inviati da soggetti che operano per conto della Regione e producono dati di aggiornamento per tutte le tipologie di contenuti su di una zona di aggiornamento definita. Tali soggetti agiscono sia sulla scorta di tutti i dati di aggiornamento inviati dai soggetti locali che sulla scorta di eventuali fonti di aggiornamento massive, quali nuove orto immagini, producendo insiemi di dati complessivamente consistenti e congruenti. Il processo di gestione prevede che tutti gli aggiornamenti, in particolare quelli proposti da Soggetti Locali, vengano opportunamente validati, eventualmente collaudati e, se conformi, depositati in un Repository specifico per poi essere successivamente trattati in funzione della loro tipologia e del loro impatto sugli oggetti presenti nel DBTR attuale. Nel caso in cui le proposte di aggiornamento rispettino una serie di condizioni tecnicheorganizzative, il processo, previa autorizzazione da parte del Gestore del DBTR, esegue la 4

5 ALLEGATO 1.3 ILSISTEMA DI GESTIONE transazione sul DBTR, altrimenti la proposta resta nel Repository e verrà successivamente utilizzata quale fonte informativa da parte della Regione per la redazione di aggiornamenti massivi. Qualora non vengano superate le validazioni ed i collaudi previsti, i dati proposti per l aggiornamento verranno respinti al mittente con adeguate comunicazioni intese sia come informative che come supporto alla correzione. Le proposte di aggiornamento inviate devono essere corredate dell adeguata metainformazione sui dati di aggiornamento; il processo di gestione dovrà trattarla in modo opportunovalidandola e memorizzandola nel Repository, in modo tale da poter derivare la necessaria metainformazione di prodotto. Dal punto di vista della storicizzazione dei dati, il processo di gestione deve supportare appieno le caratteristiche di storicizzazione del DBTR indicate in [2]. Allo scopo di favorire le attività dei soggetti che operano per costruire ed inviare gli aggiornamenti, verranno resi disponibili servizi a supporto della corretta costruzione dei dati di aggiornamento ed in particolare servizi di pre-validazione dei dati. Oltre ai dati di aggiornamento, che hanno valenza di dati certificati e strutturati, è previsto un sistema per recepire segnalazione di anomalie, ad opera di soggetti autorizzati, che potranno essere impiegate quale ulteriore risorsa informativa dai soggetti che producono gli aggiornamenti. 5

6 CAPITOLATO SISTEMA PER LA GESTIONE E FRUIZIONE DEL DBTR Per meglio illustrare tale processo vengono di seguito individuati Soggetti, Ruoli, Dati e le fasi principali del processo di gestione: Definizioni e glossario Qui sotto sono riportate Database Topografico Regionale (DBTR) Rappresenta il Database Topografico principale, così come è rappresentato nel DBMS di riferimento, contenente la versione attuale consolidata. Specifiche Database topografico Regionale L insieme dei documenti di specifica tecnica del DBTR. Modello Logico DBTR Modello logico relativo al Database Topografico Regionale Proposta di Aggiornamento (Proposta) Rappresenta un insieme di dati di aggiornamento opportunamente strutturato secondo un modello dati e definito in modo tale che possa essere validato e di cui possano essere individuate le meta informazioni necessarie a garantire la certificazione. Segnalazione di anomalia Rappresenta l indicazione classificata di una anomalia riscontrata sul DBTR rispetto a quanto rilevato sul terreno. La segnalazione non contiene dati certificati e strutturati per procedere all aggiornamento. Può avere allegati dati di tipo cartografico / CAD a supporto della segnalazione. Validazione Rappresenta l attività di verifica dei vincoli di modello e dei requisiti di qualità previsti dal modello logico e dalle specifiche del Database Topografico Regionale. L attività è automatizzabile e i controlli applicabili all intero dataset in oggetto. 6

7 ALLEGATO 1.3 ILSISTEMA DI GESTIONE Controllo a Campione Rappresenta l attività di verifica complessiva dei contenuti del DBTopografico. Essa prevede una verifica dei risultati della Validazione e l eventuale controllo a campione secondo quanto previsto dalle specifiche del DBTR. L attività è operata da un soggetto preposto e può essere supportata da specifiche funzioni (es: definizione di campioni, generazione di report, ecc..) Collaudatore E il ruolo di chi opera i controlli a campione sui contenuti, nelle modalità e nei termini indicati dalle specifiche tecniche e dal Gestore Gestore del DBTR (Gestore) E il gestore generale e responsabile del DBTR Collaudo Rappresenta la verifica complessiva sotto la responsabilità del Gestore del DBTR, previa validazione ed eventuale controllo a campione. Titolare proposte di aggiornamento (Soggetto Titolare) Rappresenta il ruolo, istituzionale, di chi è titolato ad interagire con il sistema inviando proposte di aggiornamento certificate. Tale ruolo prevede il rispetto di precise regole tecniche e organizzative individuate nell ambito di collaborazioni. Utente segnalatore Rappresenta il ruolo di chi è abilitato ad inviare segnalazioni di anomalie. Backoffice Regionale Indica oltre che un Ruolo, anche l insieme delle attività svolte a livello di gestione del DBTR allo scopo di operare aggiornamenti, su di una data zona di aggiornamento, utilizzando le Proposte pervenute e presenti nel repository, le segnalazioni perventue e e presenti nel repository di segnalazioni e altre fonti disponibili, quali le ortoimmagni. 7

8 CAPITOLATO SISTEMA PER LA GESTIONE E FRUIZIONE DEL DBTR Backoffice Locale Indica oltre che un Ruolo, anche l insieme delle attività tali per cui presso il SIT Locale, vengono composte le Proposte di Aggiornamento, in relazione alle fonti di aggiornamento disponibili, come ad esempio quelle derivanti ACI o da altri progetti, ed relazione al DBTR consolidato. A differenza del Backoffice Regionale, le attività del Backoffice Locale possono essere in parte o del tutto automatizzate in relazione alla tipologia di oggetti trattati e alla tipologia di oggetti presenti nel DBTR consolidato. Repository delle Proposte di Aggiornamento E il repertorio specifico in cui saranno memorizzate tutte le proposte di aggiornamento che transitano nel sistema. (Repository proposte) Repository delle Segnalazioni E il repertorio specifico in cui saranno memorizzate tutte le segnalazioni che il sistema riceve. Transazione sul DBTR Attività relativa alla sequenza di operazioni sul DBTR tali per cui queste sono operate complessivamente in modo atomico, previa Begin Transaction, successivo Committ o eventuale Rollback. 8

9 ALLEGATO 1.3 ILSISTEMA DI GESTIONE Requisiti del Sistema di gestione Di seguito l elenco dei requisiti minimi richiesti al sistema di gestione: R1 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 nel Doc. [2]. R2 Deve essere implementato un modello di aggiornamento di tipo distribuito. R3 Devono essere definiti Ruoli, Flussi e Processi che modificano il DBTR, attraverso proposte di aggiornamento e la loro approvazione. R4 Le proposte di aggiornamento debbono essere organizzate in un Repository che ne mantenga nel tempo la traccia R5 Devono essere esposti servizi che supportino la redazione delle Proposte di aggiornamento a livello locale. R6 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 documento [2]. R7 Il Sistema deve prevedere, nell ambito dei processi di validazione e aggiornamento, adeguate comunicazioni verso i soggetti proponenti riguardo non congruenze o approvazioni. R8 Oltre alle proposte di aggiornamento il sistema deve implementare un sistema di segnalazioni ad opera di soggetti registrati per la segnalazione di anomalie relative al DBTR consolidato. Le segnalazioni dovranno essere depositate in uno specifico Repository. R9 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. 9

10 CAPITOLATO SISTEMA PER LA GESTIONE E FRUIZIONE DEL DBTR R10 Deve essere definito il contenuto in dettaglio delle Proposte di aggiornamento, già indicato sinteticamente in [2], in modo tale da contenere tutte le informazioni necessarie al loro trattamento secondo quanto indicato nei punti precedenti (Validazione, Invio, Trattamento, Storicizzazione, ecc ). Concettualmente le proposte si comporranno di: Individuazione della Zona di aggiornamento, Contenuto DBTR di aggiornamento sulla zona individuata, riferimenti agli oggetti DBTR consolidato coinvolti, Metadati ISO relativi alla zona, altre informazioni. R11 Deve essere progettato il formato di interscambio relativo ai contenuti del DBTR delle proposte di aggiornamento in modo congruente al Modello Logico del DBTR (documento [5]), così come devono essere progettati formati dati complessivi per le Proposte di aggiornamento, comprendendo tutti i contenuti a supporto. R12 I servizi che il sistema renderà disponibili verso i soggetti locali per la redazione, la validazione e l inoltro delle proposte di aggiornamento, dovranno essere esposti tramite interfacce adeguate: sia attraverso un interfaccia applicativa (WS) che tramite specifiche applicazioni Web. R13 Il processo di aggiornamento del DBTR deve supportare adeguatamente la gestione della metainformazione in riferimento a quanto indicato nel documento [2] ed in relazione agli strumenti che la Regione mette a disposizione in tema di Metadati, indicati nel Doc. [3]. R14 Il processo di aggiornamento del DBTR deve supportare adeguatamente la storicizzazione dei dati in modo tale da consentire le interrogazioni storiche, così come indicato nel documento [2], relativo alle caratteristiche del DBMS, e nel documento [3] sulla fruizione dei dati. R15 Il Sistema deve rendere disponibili al Gestore del DBTR, gli strumenti e le funzionalità tali per cui possa operare adeguatamente nella gestione degli aggiornamenti, come ad esempio le validazioni finali, in relazione ai processi di aggiornamento. R16 Il sistema deve implementare le funzionalità necessarie affinché il Backoffice Regionale possa accedere e selezionare opportunamente le proposte di aggiornamento e le segnalazioni presenti nel Repository e procedere nelle attività costruzione dei dataset di aggiornamento di propria competenza, e nelle successive attività di validazione e inserimento di tali aggiornamenti. 10

11 ALLEGATO 1.3 ILSISTEMA DI GESTIONE Il processo di gestione degli aggiornamenti Nell architettura del sistema si ipotizza che gli aggiornamenti avvengono ad opere di Proposte di Aggiornamento che vengono trasmesse al sistema da parte, dei Soggetti Locali, che agiscono e si interfacciano tramite i Backoffice locali, e dalla RER, che agisce ed opera tramite il Backoffice Regionale. Proposte di Aggiornamento Le Proposte di Aggiornamento, descritte in [2] sul DBMS Georelazionale, sono composte dalle seguenti sezioni informative: Zona di aggiornamento riferita al DBTR Formato di scambio dei contenuti di aggiornamenti Oggetti DBTR coinvolti (modificati, cessati, modificati nei soli attributi, modificati nei soli attributi geometrici, ecc..) Metainformazione ISO relativa alla zona di aggiornamento Altra documentazione strutturata 11

12 CAPITOLATO SISTEMA PER LA GESTIONE E FRUIZIONE DEL DBTR Per ciascuna di queste sezioni dovrà essere adottato e definito il proprio modello di riferimento e dovranno essere definiti gli opportuni controlli che le funzioni di Validazione dovranno effettuare, ed eventualmente i controlli a campione che su indicazione del Gestore dovranno poter essere effettuati. La sezione Formato di Scambio riguarda il contenuto vero e proprio del DBTR, il cui modello dati è già definito dalle specifiche tecniche così come tutti i controlli che su di esso sono previsti. Il Backoffice Locale Altra ipotesi è quella che presso i Soggetti Locali, ed in particolare nell ambito dei Sistemi Informativi Territoriali, siano presenti strutture strumentali, i Backoffice Locali, che operano avvalendosi sia di opportune procedure che di operazione di Editing, per costruire e trasmettere al Sistema di gestione le Proposte di Aggiornamento del DBTR. A tal fine si suppone che i Backoffice Locali possano interfacciarsi con i sistemi interni al Soggetto Locale 1, come in particolare i processi derivanti dalla gestione del territorio, e con le sue basi dati territoriali. Come già sottolineato, la Proposta di aggiornamento rappresenta, nel rispetto di un preciso modello, un contenitore flessibile e tale per cui possano essere inviate Proposte relative all aggiornamento di un solo oggetto del DBTR, così come di una intera porzione di DBTR completa in ogni sua classe. Il Backoffice Locale dovrà inoltre interfacciarsi al Sistema, sia per la validazione e la trasmissione finale della Proposta, sia per avvalersi delle informazioni presenti nel DBTR, attuale, e dei contenuti dei Repository delle Proposte e del Repository delle Segnalazioni qualora questi contengono informazioni utili. Il Sistema di Gestione dovrà prevedere quindi gli opportuni servizi a supporto dei Soggetti Locali e dei loro Backoffice. Il Backoffice Regionale Analogamente si è ipotizzato che la Regione, si avvalga di una struttura preposta alla redazione degli aggiornamenti ordinari e straordinari. Si ipotizza che il Backoffice Regionale si interfacci con il Sistema di gestione con servizi e modalità del tutto analoghe ai Backoffice Locali, salvo naturalmente avere competenze differenti e quindi richiedere servizi specifici. Il Backoffice Regionale farà accesso ai Repository delle Proposte e al Repository delle Segnalazioni, e si avvarrà di eventuali altre fonti di aggiornamento massivo (ad esempio orto immagini), allo scopo di redigere una Proposta di Aggiornamento del tutto analoga alle precedenti e nel medesimo formato. 1 Si ipotizza, ad esempio che tali sistemi di back office Locali si interfaccino opportunamente con i dati realtivi agli applicativi ACI, così come gli applicativi di gestione della viabilità (SIS Comuni). 12

13 ALLEGATO 1.3 ILSISTEMA DI GESTIONE In generale, il Backoffice Regionale opererà su zone ampie e nell ambito di processi di aggiornamento pre-organizzati (ordinari e straordinari), ma, ciò detto, i servizi di Pre-validazione e trasmissione delle proposte nonché di accesso al DBTR ed ai Repository saranno del tutto analoghi a quelli del Backoffice Locale. 13

14 CAPITOLATO SISTEMA PER LA GESTIONE E FRUIZIONE DEL DBTR I Flussi delle Proposte Lo schema dei flussi illustra i soli flussi relativi alle Proposte di Aggiornamento e alle Segnalazioni, senza mostrare nè le fasi di validazione e di controllo a campione, né i flussi relativi alle comunicazioni (di controllo) tra i back office e il sistema. Repository delle Proposte di Aggiornamento Ruolo centrale del sottosistema di aggiornamento è rivestito dal Repository delle Proposte. Il Repository contiene e mantiene memorizzate tutte le Proposte di aggiornamento che fluiscono nel sistema e che saranno accessibili sia per successive azioni che il processo di gestione dovrà svolgere, sia per consentire un accesso attraverso opportuni filtri spaziali e temporali per i soggetti che dovranno utilizzare le proposte. Il Repository potrà avere anche un ruolo di storico delle proposte e quindi andrà opportunamente configurato. 14

15 ALLEGATO 1.3 ILSISTEMA DI GESTIONE Repository delle Segnalazioni Ruolo analogo avrà il Repository delle Segnalazioni, che trattandosi di dati con un ruolo più semplice dovranno solamente essere memorizzate e rese disponibili ai soggetti che dovranno comporre proposte di aggiornamento (back office locale e back office regionale). I controlli di qualità. Come indicato sopra, le Proposte di Aggiornamento devono rispettare i modelli dati e le specifiche tecniche previste per il DBTR. Il processo di gestione prevede quindi che vengano effettuati i necessari controlli affinché, fin dall origine, le Proposte di Aggiornamento siano conformi. Nel processo vengono distinte le azioni di Validazione, ovvero di verifica di tutti i controlli automatizzabili (Controlli Interni), operate tramite specifici servizi ne funzioni software, rispetto alle azioni di Controllo a Campione, che prevede, previa Validazione, una serie di controlli da effettuarsi a Campione e in genere NON automatizzabile, cioè ad opera di un operatore. Le specifiche del Database Topografico e del Formato di Scambio, definiscono sia i controlli per la validazione, che i controlli a campione da effettuarsi sui contenuti DBTR delle proposte di aggiornamento. Mentre per ciò che riguarda gli altri contenuti della Proposta di Aggiornamento, questi andranno definiti insieme al loro modello dati. Il sistema deve permettere una gestione flessibile dell elenco e della tipologia di controlli da effettuarsi in modo da permettere al Gestore del DBTR di operare scelte e aggiornamenti alle specifiche tecniche. Allo scopo di anticipare il più possibile la cattura e la gestione di possibili non conformità, il processo prevede che fin dai backoffice che producono le Proposte sia possibile effettuare i controlli e documentarne i risultati nella proposta stessa. In particolare è previsto che le proposte di Aggiornamento vengano sottoposte a Validazione preventiva, ovvero pre-validazione, operata prima della loro trasmissione formale. All atto della ricezione formale, la proposta sarà sottoposta a validazione, quale verifica interna al sistema, e solo se considerata Valida verrà inserita nel Repertorio insieme a tutte le informazioni necessarie per qualificarla opportunamente. Se la proposta risulterà valida potrà, su indicazione del Gestore, essere sottoposta ai Controlli a campione o meno. Il sistema dovrà quindi permettere l applicazione flessibile di politiche di controllo a campione in funzione delle specifiche esigenze del gestore del DBTR; tali Politiche, 15

16 CAPITOLATO SISTEMA PER LA GESTIONE E FRUIZIONE DEL DBTR infatti, potranno cambiare nel tempo in funzione di vari fattori (tipologia di oggetti coinvolti, soggetto locale proponente, ecc..). Per ciò che riguarda i controlli il sistema deve quindi prevedere: Insieme di funzionalità per l esecuzione della Validazione delle Proposte: tali funzionalità sono ipotizzabili come upgrade opportuno delle funzionalità della Moka DBTopografico attualmente disponibili e a riuso ; Insieme di funzionalità per la reportistica relativa alle validazioni; Insieme di funzionalità a supporto del Gestore per la definizione delle politiche di controllo a campione; Insieme di funzionalità a supporto dello svolgimento dei controlli a campione da parte del soggetto preposto ad operare i controlli a campione (Collaudatore), ivi compresa la redazione della reportistica relativa; Insieme di funzionalità per le necessarie comunicazioni ai soggetti redattori delle Proposte sottoposte a controllo, sia in caso positivo che in caso di non conformità, inoltrando i report relativi e i dati che è possibile produrre a supporto delle correzioni. I report relativi ai controlli effettuati, Validazioni ed eventuali Controlli a campione, saranno memorizzati nel Repository a corredo delle relative Proposte. Valutazione della possibilità di inserimento automatico della Proposta Una volta validata ed eventualmente collaudata, la Proposta dovrà essere sottoposta ad una analisi tramite procedure specifiche allo scopo di valutare l impatto che queste hanno sia sul DBTR esistente che su altri aggiornamenti in corso. Tali procedure quindi dovranno: Verificare il contenuto della Proposta in termini di oggetti contenuti e oggetti DBTR modificati; Confrontare le Proposte con il contenuto del DBTR nella medesima zona; Verificare se sulla medesima zona esistono altre Proposte di Aggiornamento ancora non recepite nel DBTR; Produrre un apposito report su azione del Gestore per definire la proposta Collaudata ed inseribile nel DBTR. Quindi, a valle di queste ulteriori analisi, il Gestore, sulla base di politiche che saranno oggetto di approfondimento nel corso della progettazione di dettaglio ma sulle quali alcune indicazioni di massima sono date anche in [2], può dichiarare la proposta Collaudata e indicare al Sistema che è possibile procedere al suo inserimento nel DBTR. 16

17 ALLEGATO 1.3 ILSISTEMA DI GESTIONE Quest ultima fase di scelta, definendo nei dettagli le opportune condizioni, può essere automatizzata. Si citano ad esempio due possibili casi positivi (a. e b.) e due possibili casi negativi (c. e d.): a. La proposta è stata prodotta quale aggiornamento ordinario e ricopre interamente un intero comune su tutte le classi previste: in tal caso, una volta che la proposta è validata e collaudata, può essere inserita nel DBTR in sostituzione della zona di aggiornamento senza temere incongruenze. b. La proposta consiste in un solo oggetto isolato, ad esempio un nuovo Edificio (classe EDI) che non ha alcun impatto con i contenuti del DBTopo se non su di una zona Antropizzata generica (classe AZI) utilizzata anche come limite della zona di aggiornamento. In tal caso una volta che la proposta è validata e collaudata, può essere inserita nel database senza generare incongruenze. c. La proposta contiene l aggiornamento di una serie di Aree di circolazione Stradali (ACS) che ha un forte impatto con molti e differenti oggetti presenti nel DBTR senza che questi siano stati rilevati in modo congruente con gli aggiornamenti dell ACS (noto tramite i metadati di istanza): il Gestore potrà applicare la politica di sospensione in attesa di provvedere ad una riconciliazione di tutte le geometrie nell ambito di una aggiornamento straordinario. d. Se sulla stessa zona di aggiornamento relativo ad una proposta esiste, nel Repertorio, un altra Proposta presentata da un altro soggetto, situazione di interazione sul territorio che può verificarsi ad esempio tra chi propone aggiornamenti all Edificato e chi propone aggiornamenti alle Strade Provinciali, il Gestore dovrà poter applicare una politica tale per cui ambedue le proposte vengono sospese e restano nel Repository in attesa che, tramite il Backoffice Regionale, vengano fuse, nell ambito di aggiornamenti ordinari, in una proposta che recepisce in modo congruente entrambi gli aggiornamenti. Inserimento della Proposta nel DBTR Superata questa fase, ogni Proposta dichiarata Collaudata verrà inserita nel DBTR attraverso le funzioni di servizio per la transazione, descritte sinteticamente in [2]. Tali servizi produrranno gli opportuni report che verranno anch essi inseriti nel Repository delle Proposte. 17

18 CAPITOLATO SISTEMA PER LA GESTIONE E FRUIZIONE DEL DBTR 18

19 ALLEGATO 1.3 ILSISTEMA DI GESTIONE Servizi e funzionalità esposti verso i Backoffice Locali Il Sistema di gestione dovrà esporre una serie di servizi, allo scopo di supportare le attività necessarie alla redazione delle Proposte di Aggiornamento composte secondo quanto previsto nel progetto. In particolare andranno resi disponibili: 1. Viste specifiche del DBTR, attuale, allo scopo di supportare: le funzioni di definizione dei limiti delle zone su cui interviene l aggiornamento; le funzioni di inserimento nella Proposta dell indicazione degli oggetti del DBTR coinvolti nell aggiornamento (cessati, modificati, ecc..) 2. Viste specifiche del Repository delle Proposte allo scopo di rendere disponibili eventuali altre Proposte pendenti, sulla medesima Zona o sulle zone adiacenti 3. Viste specifiche del Repository delle Segnalazioni allo scopo di rendere disponibili le segnalazioni pendenti sulla zona di aggiornamento 4. Servizi di Pre-validazione, che permettono di verificare in modo formale la validità della Proposta di Aggiornamento rispetto ai controlli di qualità interni, ovvero rispetto alle specifiche del Formato dati, come sviluppo del sistema di controlli Moka DBTopo. I servizi prevedono la restituzione di un opportuna reportistica per la comprensione delle non conformità e il supporto nella loro correzione. 5. Servizi di Trasmissione formale della Proposta, che permettano al Soggetto Locale di inviare in modo autenticato e sicuro la Proposta al Sistema di Gestione. 6. Servizi di comunicazione dello Stato della proposta, ovvero le sue ulteriori validazioni, la relativa reportistica, lo stato di avanzamento nel processo di inserimento nel DBTR, ecc.. 19

20 CAPITOLATO SISTEMA PER LA GESTIONE E FRUIZIONE DEL DBTR Di seguito uno schema che riassume il sistema di interscambio relativo a tali servizi. 20

21 ALLEGATO 1.3 ILSISTEMA DI GESTIONE Servizi e funzionalità esposti verso il Backoffice Regionale Analogamente all interfaccia verso il Backoffice Locale, il Sistema dovrà esporre servizi equivalenti verso il Backoffice Regionale. Da un lato perché è presumibile che le attività relative al Backoffice regionale siano svolte da uno o più soggetti incaricati anche esterni alla Regione, dall altro perché, essendo le funzioni e le modalità di relazione tra il Backoffice Regionale e il Sistema di gestione molto simili, si ritiene corretto e prevedere per le medesime funzioni i medesimi servizi, eventualmente ricalibrati per tenere conto delle tipicità degli aggiornamenti ordinari e straordinari di cui in genere verrà incaricato il Backoffice Regionale. Riassumendo quindi si confermano i servizi di: 1. Viste specifiche del DBTR, attuale, allo scopo di supportare: le funzioni di definizione dei limiti delle zone su cui interviene l aggiornamento; le funzioni di inserimento nella Proposta dell indicazione degli oggetti del DBTR coinvolti nell aggiornamento (cessati, modificati, ecc..) 2. Viste specifiche del Repository delle Proposte allo scopo di rendere disponibili eventuali altre Proposte pendenti, sulla medesima Zona o sulle zone adiacenti 3. Viste specifiche del Repository delle Segnalazioni allo scopo di rendere disponibili le segnalazioni pendenti sulla zona di aggiornamento 4. Servizi di Pre-validazione, che permettono di verificare in modo formale la validità della Proposta di Aggiornamento rispetto ai controlli di qualità interni, ovvero rispetto alle specifiche del Formato dati, come sviluppo del sistema di controlli Moka DBTopo. I servizi prevedono la restituzione di un opportuna reportistica per la comprensione delle non conformità e il supporto nella loro correzione. 5. Servizi di trasmissione formale della Proposta, che permetteranno al backoffice Regionale inviare in modo formale la Proposta al sistema di gestione. 6. Servizi di comunicazione in relazione allo stato della proposta, le sue ulteriori validazioni e controlli a campione, la relativa reportistica. 21

22 CAPITOLATO SISTEMA PER LA GESTIONE E FRUIZIONE DEL DBTR Servizi e funzionalità esposti verso il Collaudatore Analogamente alle interfaccia verso i Backoffice, il Sistema dovrà esporre servizi analoghi a supporto delle attività di Controllo a campione. Ciò corrisponderà sostanzialmente ad un meccanismo che è l evoluzione del meccanismo già in atto con l applicativo Moka DBTopo. In Sintesi dovrà prevedere: 1. Servizi di accesso al Repository per disporre delle Proposte di Aggiornamento che devono essere sottoposte al Controllo a campione; 2. Sistemi di comunicazione per l invio da parte del Collaudatore verso il Sistema di gestione e verso il Repository delle proposte, della reportistica sui controlli effettuati e i loro esiti: ciò comprende anche gli eventuali dati de necessari alla comprensione delle non conformità riscontrate 22

23 ALLEGATO 1.3 ILSISTEMA DI GESTIONE Riferimenti Metadati descrittivi (secondo le specifiche definite in Allegato 2 (Specifiche tecniche per la formazione e l alimentazione del Repertorio Nazionale dei Dati Territoriali) allo schema di DPCM: 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/ Regione Emilia-Romagna: Strumenti cartografici digitali a supporto della pianificazione - Atto di indirizzo e coordinamento tecnico per l attuazione della LR 24 marzo 2000, n. 20, art. A-27 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 Norme definite in materia di DB Topografico a livello nazionale dall Intesa Stato, Regioni, Enti Locali sui Sistemi Informativi Geografici pubblicati sul sito Regione Emilia-Romagna: DB Topografico alle grandi scale contenuto e struttura concettuale e il successivo Regione Emilia-Romagna: DB Topografico alle grandi scale Allegato integrativo di contenuto e struttura concettuale Regione Emilia-Romagna: Modello logico del Database Topografico Regionale Regione Emilia-Romagna: Data Base Topo alle grandi scale formato di trasferimento e sua struttura fisica e la successiva specifica di Integrazione dei dati per la resa grafica 23

24 CAPITOLATO SISTEMA PER LA GESTIONE E FRUIZIONE DEL DBTR Regione Emilia-Romagna: Specifiche dei requisiti di qualità e della loro applicazione al formato di scambio Regione Emilia-Romagna: DB Topografico: Dizionario dati Regione Emilia-Romagna: Allestimento del DB Topografico in modalità B:Linee Guida 24