- Geoportale della Lombardia

Aggiornamento
Data Base Topografico
Armonizzazione e Interscambio
tra CST e Regione
Giuseppe Pelagatti
[email protected]
Milano, 6 aprile 2011
INDICE
Richiamo dell’impostazione generale
Definizione dei contenuti e formato di interscambio
Lotti di aggiornamento
Controlli di integrità e produzione di metadati di
istanza
5. Aggiornamenti al confine tra diversi gestori
6. Allineamento iniziale tra DBTL e DBTR e
realizzazione dell’estrattore
7. Proposta di un modo di procedere
1.
2.
3.
4.
© 2011 - Pelagatti Giuseppe
2
1. Impostazione generale
• Capitolo 5 e Approfondimento tecnico N. 4
– Architettura di riferimento
– Il Database Topografico della Regione (DBTR) contiene una
rappresentazione dell’intero territorio regionale
– il territorio regionale è suddiviso in porzioni disgiunte
– Il DBTR può essere concettualmente suddiviso in altrettante
porzioni, senza violare la continuità della rappresentazione
territoriale
– Ogni porzione è gestita da un «Gestore» (possibilmente un CST)
– Ogni Gestore possiede un proprio database locale (DBTL)
– Il Gestore organizza il proprio DBTL autonomamente, sia come
tecnologia che come strutturazione
– Il DBTL deve contenere i dati che, opportunamente ristrutturati,
costituiscono la porzione di DBTR di riferimento del Gestore
© 2011 - Pelagatti Giuseppe
Il DBT locale (DBTL)
• L’insieme degli shapefile di produzione NON costituisce un DBT locale
• Per ottenere un DBT locale è necessario caricare gli shapefile in un sistema di
gestione dei database, ad esempio:
–
–
–
–
ESRI SDE + DB relazionale
Oracle Spatial
Postgis
ecc….
• La creazione di un DBT richiede di progettarne e definirne lo schema (schema
fisico locale) e poi di caricarvi i dati
• La progettazione dello schema fisico locale normalmente è guidata dagli scopi
applicativi del DBT
• Le applicazioni si basano sulla conoscenza di tale schema, quindi non è
semplice cambiare lo schema di un sistema utilizzato da molte applicazioni
• I dati che vengono condivisi nella IIT dovranno essere presenti nel DBTL, ma
in generale il DBTL conterrà altri dati
• Molti sistemi permettono di caricare un insieme di shapefile ottenendo
automaticamente uno schema
© 2011 - Pelagatti Giuseppe
Funzionamento della IIT
contenuti locali
(includono quelli condivisi)
Aggiornamenti
locali
Lotto di
Aggiornamento
DBTL
di un
gestore
Gx
ESTRATTORE
DbTR
Formato di
interscambio
DBTL
Aggiornamenti
locali
di un
gestore
Gy
ESTRATTORE
tecnologia locale
(diversa da quella regionale)
© 2011 - Pelagatti Giuseppe
porzione x
porzione y
Interfaccia Dati Regolata
(si appoggia sui protocolli
di comunicazione)
«Inizializzazione» dei DBTL
• Al momento della Adesione di un Gestore alla IIT deve essere creato uno
stato iniziale corretto
• Lo stato iniziale deve garantire l’allineamento tra i dati del Gestore e la
corrispondente porzione di DBTR
• La «porzione di DBTR» possiederà le seguenti caratteristiche:
– Dati armonizzati geometricamente ai confini con altre porzioni, gestite
da Gestori che hanno aderito precedentemente
– Dati armonizzati con dati di CT10, con individuazione degli «Oggetti
Globali» (ad esempio, strade extraurbane, grandi laghi, ecc…)
– Eventuali altre correzioni apportate nella fase di caricamento dei dati in
DBTR
• Se queste caratteristiche sono state introdotte da Regione sul DBTR, è
necessario che le modifiche vengano riportate sui dati locali, cioè nei
DBTL
© 2011 - Pelagatti Giuseppe
6
2. Definizione dei contenuti e
formato di interscambio
• Per questo problema è stata utilizzata la metodologia e gli
strumenti definiti congiuntamente dal CISIS e dal Polimi con un
progetto al quale partecipa anche RL: GeoUML Methodology
• I principi fondamentali della GeoUML methodology sono:
1. separare la definizione più astratta (concettuale) dei contenuti
dalle strutture fisiche utilizzate per rappresentarli
2. definizione di proprietà dell’informazione tramite vincoli sullo
schema concettuale
• Gli strumenti della GeoUML Methodology sono 2:
– GeoUML Catalogue
– GeoUML Validator
© 2011 - Pelagatti Giuseppe
7
GeoUML catalogue e DBTR della RL
GeoUML
catalogue
Schema Concettuale
del DBTR
(definisce i contenuti condivisi della IIT)
© 2011 - Pelagatti Giuseppe
8
Schema Concettuale nella IIT
Schema Concettuale
(definizione dei contenuti condivisi)
DBTL
di un
gestore
Gx
Lotto di
Aggiornamento
© 2011 - Pelagatti Giuseppe
DbTR
Passaggio dalle Specifiche concettuali ai
dati:
Modello Implementativo
• Schema Fisico (SF): definisce la struttura fisica;
esempi:
– XSD per un file GML
– Create Table per Georelazionale SQL
– Struttura degli Shapefile
• Modello Implementativo (MI): è un insieme di Regole che
permettono di generare uno SF da uno SC
© 2011 - Pelagatti Giuseppe
10
Generazione dello schema fisico dal
Catalogue
GeoUML Catalogue
SC del DBTR
Mapping
Generator
MI Shape
altri
Mapping
Generator
Lotto di Aggiornamento:
contenuto: SC del DBTR
formato: struttura Shape
© 2011 - Pelagatti Giuseppe
11
Schema Concettuale e MI nella
IIT
Schema Concettuale
(definizione dei contenuti condivisi)
MI shape
(formato di trasferimento)
LDbT
di un
gestore
Gx
Lotto di
Aggiornamento
© 2011 - Pelagatti Giuseppe
DbTR
Controlli sul LA
• potranno essere adattate le attuali procedure di controllo
per applicarle sui LA
inoltre
• si potrà utilizzare il GeoUML Validator per controllare
proprietà dichiarate a livello dello schema concettuale
© 2011 - Pelagatti Giuseppe
3. Lotti di Aggiornamento (minimi)
• E’ un’area la cui frontiera deve rimanere inalterata
nell’aggiornamento
• Ottenibile come inviluppo di tutti gli oggetti che circondano gli
oggetti esplicitamente aggiornati
• Nell’ambito dell’area del LA nel DBTR verrà sostituito tutto il
contenuto, riconoscendo e «storicizzando»:
– oggetti preesistenti (importanza di gestire l’identificatore)
– oggetti che vengono eliminati
– oggetti nuovi che vengono creati
© 2011 - Pelagatti Giuseppe
14
Problemi di precisione -1
• differenza tra Accuratezza e Risoluzione (interna)
• Accuratezza:
– riguarda la precisione del rilievo
– è tipicamente dell’ordine di 10-1
• Risoluzione interna:
– riguarda la precisione della rappresentazione interna delle
coordinate
– con dati rappresentati in FP64 può arrivare a 10-9 su tutto
l’extent nazionale
© 2011 - Pelagatti Giuseppe
15
Problemi di precisione -2
• E’ importante che la Frontiera dei LA resti immutata per
permettere un inserimento topologicamente corretto nel DBTR
• è impossibile evitare (in un sistema eterogeneo) che nelle
trasformazioni tra DBTL, formato di interscambio e DBTR le
coordinate subiscano delle variazioni
• E’ necessario garantire che tali variazioni siano sufficientemente
piccole da poter riconoscere la corrispondenza con i vertici
preesistenti
• A questo scopo devono essere definiti dei valori di precisione dei
DBT e dei formati di interscambio
(sembra ragionevole un valore intorno a 10-5 )
© 2011 - Pelagatti Giuseppe
16
4. Controlli di integrità e produzione
di metadati di istanza
• E’ stata definita una struttura di «Metadati di Istanza»
• Un metadato di istanza caratterizza analiticamente il singolo
oggetto del DB (a differenza dei metadati di prodotto)
• Alcuni Metadati di Istanza devono essere esplicitamente indicati
dal produttore (ad esempio, l’accuratezza del rilievo)
• Altri Metadati di Istanza possono essere prodotti automaticamente
da procedure di controllo (ad esempio, la corretta copertura del
suolo)
• La completezza dei contenuti del LA permette di eseguirvi sopra
dei controlli automatici e di produrre la metainformazione di
istanza
© 2011 - Pelagatti Giuseppe
17
Riassumendo
•
La definizione dell’interfaccia dati regolata della IIT è
costituita da:
1.
2.
3.
4.
5.
Schema concettuale dei contenuti condivisi (DBTR)
Modello implementativo Shape
Regole di delimitazione del lotto di aggiornamento
Regole relative alla precisione
Metadati di istanza che devono essere trasferiti dal
livello locale a quello regionale
© 2011 - Pelagatti Giuseppe
5. Aggiornamenti al confine tra
diversi gestori
• Il problema può essere trattato in diversi modi, anche in base ai
rapporti di collaborazione che potranno essere istituiti tra diversi
gestori
• due casi limite (a titolo di esempio, perché il problema è da
studiare):
– i 2 gestori si fanno carico di produrre un LA integrato, la cui
area è a cavallo dei due territori gestiti (gli oggetti di questo
LA avranno diverse ownership, ma il LA integrato ha le
«autorizzazioni sufficienti)
– l’aggiornamento della linea di separazione del LA in due
sottolotti viene certificata opportunamente, e i due sottolotti
sono caricati separatamente nel DBTR
© 2011 - Pelagatti Giuseppe
19
6. Allineamento iniziale tra DBTL e
DBTR e realizzazione dell’estrattore
• Questo problema deve essere affrontato in maniera differenziata
in base alla situazione dei gestori, distinguendo in particolare i
seguenti casi:
• Gestori che hanno già un DBTL – i problemi di allineamento
devono essere studiati caso per caso, distinguendo i seguenti
sottocasi:
– DBTL già utilizzato con procedure applicative
– DBTL creato come caricamento di shape di produzione, ma non
ancora utilizzato da procedure applicative
• Gestori che devono ancora creare il DBTL e quindi possono
partire dai dati corretti a livello regionale
© 2011 - Pelagatti Giuseppe
20
7. Proposta di un modo di procedere
• Riunione del 27 aprile:
– presentazione dei contenuti del DBTR
– presentazione del formato di interscambio
– presentazione della struttura dei metadati di istanza
– proposta e discussione delle regole di precisione
– raccolta delle osservazioni, proposte, ecc…(estesa alle
settimane successive)
• Incontri singoli per l’allineamento e l’estrattore dei DBTL già
creati e operativi
• Riunione del 18 maggio:
– opzioni per la creazione dei nuovi DBTL
– discussione delle osservazioni e tentativo di consolidamento
© 2011 - Pelagatti Giuseppe
21
Scheda relativa alla situazione dei DBTL
• Esiste DBTL con procedure applicative
• Esiste DBTL, non ancora utilizzato
– DBTL è un puro caricamento degli shape di produzione
– DBTL è stato progettato appositamente
• Non esiste ancora il DBTL - Si hanno preferenze
tecnologiche
© 2011 - Pelagatti Giuseppe