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
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
ALLEGATO 1.3 – IL SISTEMA 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 ............................................................... 11
Proposte di Aggiornamento............................................................................................................ 11
Il Backoffice Locale....................................................................................................................... 12
Il Backoffice Regionale.................................................................................................................. 12
I Flussi delle Proposte ................................................................................................................... 14
Repository delle Proposte di Aggiornamento .................................................................................... 14
Repository delle Segnalazioni......................................................................................................... 15
I controlli di qualità....................................................................................................................... 15
Valutazione della possibilità di inserimento automatico della Proposta................................................. 16
Inserimento della Proposta nel DBTR.............................................................................................. 17
SERVIZI E FUNZIONALITÀ ESPOSTI VERSO I BACKOFFICE LOCALI .......................................... 19
SERVIZI E FUNZIONALITÀ ESPOSTI VERSO IL BACKOFFICE REGIONALE ................................. 21
SERVIZI E FUNZIONALITÀ ESPOSTI VERSO IL COLLAUDATORE ................................................ 22
RIFERIMENTI .............................................................................................................................. 23
3
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
ALLEGATO 1.3 – IL SISTEMA 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
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
Rappresenta il Database Topografico principale, così come è
Regionale
rappresentato nel DBMS di riferimento, contenente la
(DBTR)
versione “attuale” consolidata.
Specifiche Database
L’insieme dei documenti di specifica tecnica del DBTR.
topografico Regionale
Modello Logico DBTR
Modello logico relativo al Database Topografico Regionale
Proposta di Aggiornamento
Rappresenta un insieme di dati di aggiornamento
opportunamente strutturato secondo un modello dati e
(Proposta)
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
ALLEGATO 1.3 – IL SISTEMA 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
E’ il gestore generale e responsabile del DBTR
(Gestore)
Collaudo
Rappresenta la verifica complessiva sotto la responsabilità
del Gestore del DBTR, previa validazione ed eventuale
controllo a campione.
Titolare proposte di
Rappresenta il ruolo, istituzionale, di chi è titolato ad
aggiornamento
interagire con il sistema inviando proposte di aggiornamento
(Soggetto Titolare)
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
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
E’ il repertorio specifico in cui saranno memorizzate tutte le
Proposte di Aggiornamento
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
ALLEGATO 1.3 – IL SISTEMA DI GESTIONE
Requisiti del Sistema di gestione
Di seguito l’elenco dei requisiti minimi richiesti al sistema di gestione:
R1
R2
R3
R4
R5
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].
Deve essere implementato un modello di aggiornamento di tipo distribuito.
Devono essere definiti Ruoli, Flussi e Processi che modificano il DBTR, attraverso proposte di
aggiornamento e la loro approvazione.
Le proposte di aggiornamento debbono essere organizzate in un Repository che ne mantenga
nel tempo la traccia
Devono essere esposti servizi che supportino la redazione delle Proposte di aggiornamento a
livello locale.
Il sistema deve consentire, quando possibile e nei limiti dei necessari controlli e validazioni da
R6
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.
Oltre alle proposte di aggiornamento il sistema deve implementare un sistema di segnalazioni
R8
ad opera di soggetti registrati per la segnalazione di anomalie relative al DBTR consolidato. Le
segnalazioni dovranno essere depositate in uno specifico Repository.
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
R9
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
CAPITOLATO SISTEMA PER LA GESTIONE E FRUIZIONE DEL DBTR
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
R10
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
ALLEGATO 1.3 – IL SISTEMA 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..)
11
•
Metainformazione ISO relativa alla zona di aggiornamento
•
Altra documentazione strutturata
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 Locale1, 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
ALLEGATO 1.3 – IL SISTEMA 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
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
ALLEGATO 1.3 – IL SISTEMA 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
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
ALLEGATO 1.3 – IL SISTEMA 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
CAPITOLATO SISTEMA PER LA GESTIONE E FRUIZIONE DEL DBTR
18
ALLEGATO 1.3 – IL SISTEMA 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
CAPITOLATO SISTEMA PER LA GESTIONE E FRUIZIONE DEL DBTR
Di seguito uno schema che riassume il sistema di interscambio relativo a tali servizi.
20
ALLEGATO 1.3 – IL SISTEMA 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
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
ALLEGATO 1.3 – IL SISTEMA 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: http://www.cnipa.gov.it/site/itIT/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 1-2004
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
www.IntesaGIS.it.
•
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
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
