- Geoportale della Lombardia

Il modello GeoUML e gli strumenti Catalogue e
Validator
nell’Interscambio tra DBTL e DBTR
Giuseppe Pelagatti
[email protected]
8 giugno 2011
INDICE
1. Ruolo degli strumenti Catalogue e Validator nella IIT
2. Concetti fondamentali del modello GeoUML
3. La progettazione e implementazione dei DBTL nuovi
Dimostrazione del GeoUML Validator
Nota Bene: non si vuole fornire una presentazione esaustiva del
GeoUML e degli strumenti, ma approfondire la comprensione degli
aspetti più importanti per il funzionamento della IIT
© 2011 - Pelagatti Giuseppe
2
1)Ruolo degli strumenti
Catalogue e Validator nella 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)
GeoUML catalogue
GeoUML
catalogue
Schema Concettuale
del DBTR
(definisce i contenuti condivisi della IIT)
© 2011 - Pelagatti Giuseppe
4
Passaggio dalle Specifiche concettuali ai
dati:
Modello Implementativo
• Schema Fisico (SF): definisce la struttura fisica;
• Modello Implementativo (MI): è un insieme di Regole che
permettono di generare uno SF da uno SC
• MI Shape_Flat: è una struttura fisica progettata appositamente
per rappresentare il contenuto concettuale in formato Shapefile
© 2011 - Pelagatti Giuseppe
5
Generazione dello schema fisico dal
Catalogue
GeoUML Catalogue
SC del DBTR
Mapping
Generator
Shape_Flat
Lotto di Aggiornamento:
contenuto: SC del DBTR
formato: struttura Shape
© 2011 - Pelagatti Giuseppe
6
Schema Concettuale nella IIT
Schema Concettuale
(definizione dei contenuti condivisi)
(mapping manuale)
Shape_Flat
DBTL
di un
gestore
Gx
Lotto di
Aggiornamento
© 2011 - Pelagatti Giuseppe
DBTR
GeoUML Validator
GeoUML
catalogue
SC.scs
Dataset
da validare
GeoUML
validator
© 2011 - Pelagatti Giuseppe
Messaggi
diagnostici
8
Validator e Lotto di Aggiornamento
GeoUML Catalogue
SCDBTR
Mapping
Generator
Shape_Flat
SCDBTR.scs
Lotto di
Aggiornamento
(formato
Shape_Flat)
GeoUML Validator
Reader
per
Shape_Flat
Controlli
(geometrie,
Vincoli)
© 2011 - Pelagatti Giuseppe
DB
delle
diagnosi
Query e
Reports
9
Validator nell’aggiornamento della
IIT
Schema Concettuale
(contenuti condivisi e vincoli)
Procedure
di controllo
alternative o
complementari
DBTL
di un
gestore
Validator
(presso
Gestore)
trasferimento
Validator
(presso
RL)
Lotto di
Aggiornamento
(Shape_Flat)
© 2011 - Pelagatti Giuseppe
DBTR
Validator e Procedure di controllo
(presso RL e presso Gestori)
• Premesso che
– il Validator può verificare la maggior parte delle proprietà
geometriche controllate dalle Procedure di controllo
• si hanno le seguenti differenze
– il Validator permette di inserire con facilità nuovi controlli
(basta scrivere vincoli, non procedure)
– il Validator non richiede la disponibilità della tecnologia
ESRI
© 2011 - Pelagatti Giuseppe
11
2. Il modello GeoUML
•
•
•
•
Modello geometrico
I vincoli topologici
Topologia esatta, precisione e distanza minima
Il concetto di composizione
– composizione e derivazione (ristrutturazioni degli shape di
produzione)
– composizione e attributi a tratti e sottoaree
– composizione di oggetti globali da quelli locali
© 2011 - Pelagatti Giuseppe
Modello geometrico di GeoUML
• fondamentalmente basato su SFM, con le seguenti
estensioni:
– le curve e i punti possono essere 3D
– le relazioni topologiche su punti e curve 3D sono
interpretate in 3D
– esiste una funzione planar per trasformare primitive 3D in
primitive 2D
• esempio: date 2 curve 3D, A e B, posso esplicitare la
relazione CROSS sia in 3D che in 2D:
– A (CROSS) B è interpretata in 3D
– A.pln (CROSS) B.pln è interpretata in 2D
© 2011 - Pelagatti Giuseppe
13
Modello Geometrico di GeoUML
• le superfici nei sistemi basati su SFM
– sono trattate in 2D
– ma generalmente è supportata la frontiera in 3D (polygonZ)
– le relazioni topologiche non sono ambigue, ma limitate, perchè
tutto è interpretato in 2D
• in GeoUML risultava quindi necessario un meccanismo per
esplicitare lo spazio di riferimento per l’interpretazione delle
relazioni topologiche relative alle superfici con frontiera 3D
• tale meccanismo è costiuito da un tipo geometrico, le
SurfaceB3D, che è rappresentato da una struttura con due
componenti.
– la superficie, interpretata in 2D
– la frontiera B3D, interpretata in 3D
© 2011 - Pelagatti Giuseppe
14
una SurfaceB3D fornisce una semantica
precisa a un polygonZ
• Esempio: siano P e Q punti 3D, S una SurfaceB3D; posso esprimere
– P.pln (IN) S.superficie (interpretata in 2D)
– Q (IN) S.B3D (interpretata in 3D)
S.B3D
Q
polygonZ
P
P.PLN
ambedue le relazioni sono interpretate in
2D, quindi su Q si esprime solamente la
relazione equivalente in GeoUML a
Q.pln (IN) S.superficie.BND
S.superficie
© 2011 - Pelagatti Giuseppe
15
GeoUML: vincoli topologici
I vincoli topologici sono condizioni che devono essere soddisfatte
da tutti gli stati della base di dati e che fanno riferimento alle
proprietà spaziali degli oggetti, in particolare alle relazioni
topologiche tra oggetti.
La definizione dei vincoli topologici richiede di specificare due tipi
di elementi:
• la struttura logica del vincolo
• le relazioni spaziali utilizzate nel vincolo
I vincoli non sono solamente delle proprietà che si possono
controllare (ad esempio tramite validatore) per garantire la
qualità dell’informazione territoriale, ma aiutano a esprimere il
significato degli elementi informativi presenti nello schema.
© 2011 - Pelagatti Giuseppe
16
GeoUML: relazioni topologiche
Le seguenti relazioni topologiche costituiscono un insieme completo e
mutuamente esclusivo di relazioni:
– disjoint (DJ),
– touch (TC),
– in (IN),
– contains (CT),
– equal (EQ),
– overlap (OV)
inoltre sono definite due relazioni aggiuntive (derivabili):
– Intersects (INT)
– Cross (CR) (solo tra oggetti lineari – è una specializzazione della relazione
Overlap - richiede che la dimensione dell’intersezione sia puntiforme)
© 2011 - Pelagatti Giuseppe
17
Esempi di relazioni topologiche
overlap
© 2011 - Pelagatti Giuseppe
18
Esempi di relazioni topologiche
DISJOINT
TOUCH
IN
DISJOINT
TOUCH
IN
DISJOINT
© 2011 - Pelagatti Giuseppe
EQUAL
19
Esempi di vincoli topologici
Date le classi:
ACC_PC
componenti spaziali: accessibilità, posizione
ACC_INT
componenti spaziali: posizioneIngresso
CR_EDF
componenti spaziali: Ingombro_al_suolo
© 2011 - Pelagatti Giuseppe
20
Elementi stradali
Esempi di geometrie valide
Accesso esterno
diretto
accessibilità
V1
Accesso esterno
indiretto
V1
posizione
V3
Accesso
interno
A
V2
C
Pertinenza degli
edifici
BeC
V2
V1
B
Accesso esterno
indiretto
© 2011 - Pelagatti Giuseppe
21
Esempi di vincoli topologici
1. ACC_PC.accessibilità (IN) esiste EL_STR.Tracciato
2. ACC_INT.posizioneIngresso.PLN (IN) esiste
CR_EDF.Ingombro al suolo.superficie
3. (tipo= “accesso esterno diretto”)
ACC_PC.posizione.PLN (IN) esiste
CR_EDF.Ingombro al suolo.superficie
© 2011 - Pelagatti Giuseppe
22
Rappresentazione esatta della topologia
• Il GeoUML non è ambiguo, ma è necessario che siano rispettate
alcune regole di implementazione per evitare ambiguità introdotte
dall’implementazione
• In particolare, le proprietà topologiche definite in GeoUML
devono essere implementate in maniera esatta, senza tolleranza
• La tolleranza può essere utilizzata per ottenere la rappresentazione
topologicamente esatta, come anche lo “snapping”, il “cut and
paste”, ecc...
• La rappresentazione esatta della topologia non coincide con l’uso
di strutture topologiche, ma va nella stessa direzione
© 2011 - Pelagatti Giuseppe
23
Esempio
Ipotesi: esiste il vincolo Rosso (TC) Blu
Questa situazione NON lo soddisfa
Questa situazione lo soddisfa
A
B
Questa relazione è OV,
Questa relazione è TC,
la geometria vincolata A-B è identica
nei 2 poligoni (geometria vincolata)
© 2011 - Pelagatti Giuseppe
24
Perturbazione delle geometrie
• In teoria, le geometrie presenti nel DBTR e le corrispondenti geometrie presenti
nel DBTL dovrebbero essere identiche a condizione di adottare lo stesso livello
di risoluzione
• In pratica, ciò non si verifica a causa di diversi fenomeni che causano delle
“perturbazioni” dei dati, cioè degli spostamenti piccoli (contenuti generalmente
all’interno della risoluzione)
• Tali fenomeni possono essere:
– diversa rappresentazione binaria dei dati nei sistemi regionale e locale
– interazione tra i dati di interesse regionale e i dati strettamente locali (ad
esempio, appoggiare un segnale stradale su un elemento stradale inserisce
un vertice nuovo nell’elemento, spostandolo leggermente)
• Si stanno studiando le regole per riconoscere le perturbazioni
“legittime” dagli errori di disallineamento
© 2011 - Pelagatti Giuseppe
25
Il concetto di composizione
Il concetto di composizione si presenta anzitutto tramite 2 tipi di
vincoli:
Il vincolo di composizione (CompostoDa) stabilisce che per ogni
istanza di una classe (classe vincolata) il suo attributo geometrico
sia uguale all’unione degli attributi geometrici di una o più
istanze di un’altra classe (classe vincolante).
Esempio: Cr_Edf.maxest compostoDa uvdice.sup_base.superficie
Il vincolo di partizione (Partizionato) aggiunge al vincolo di
composizione la proprietà che le geometrie componenti siano
disgiunte tra loro.
Alcuni oggetti composti, non richiesti nel capitolato di produzione,
sono ricostruiti dalle procedure di caricamento del DBTR
© 2011 - Pelagatti Giuseppe
26
Attributi a tratti (ATT) e sottoaree
Gli attributi a tratti sono attributi dotati di dominio e il cui valore non
è associato semplicemente a un oggetto applicativo ma è una
funzione dei punti che appartengono a un attributo geometrico
dell’oggetto applicativo.
Si usa un ATT invece di una classe esplicita che rappresenti i tratti,
quando non è interessante per l’applicazione rappresentare i tratti
come oggetti istanze di classi.
Nell’implementazione strutturale gli ATT sono realizzati esplicitando
le geometrie dei «Tratti minimi». Esiste un vincolo di composizione
implicito tra queste geometrie e l’oggetto applicativo decomposto in
tratti.
Gli attributi a sottoaree sono l’equivalente areale dei tratti lineari.
Nel DBTR sono state utilizzate solamente per poche classi di
manufatti
© 2011 - Pelagatti Giuseppe
27
ATT, produzione e DBTR
• Nel capitolato di produzione sono stati richiesti solamente i tratti
minimi, non gli oggetti applicativi
• Le procedure di caricamento del DBTR ricostruiscono alcuni
degli oggetti applicativi più importanti (ad esempio, gli Elementi
Stradali ES)
• Tale ricostruzione è complessa, perchè richiede di riconoscere gli
ES in base alla struttura topologica della rete stradale e costituisce
un valore aggiunto ai fini dell’uso del grafo stradale
© 2011 - Pelagatti Giuseppe
28
Composizione, oggetti globali e
oggetti locali
• La nozione di composizione è alla base del meccanismo che si sta
mettendo a punto per permettere di gestire localmente le
geometrie che costituiscono oggetti globali
• Il principio si basa sulla definizione di vincoli di composizione
degli oggetti globali in grado di permettere di rigenerare la loro
geometria componendo oggetti locali che possono essere editati
da singoli gestori
• La definizione di tali vincoli e di alcune classi funzionali a tale
scopo è in corso
© 2011 - Pelagatti Giuseppe
29
3. Progettazione e caricamento di
DBTL nuovi
• 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 (ShapeToTable)
© 2011 - Pelagatti Giuseppe
Creazione di un nuovo DBTL
tramite ShapeToTable
Shapefiles
di produzione
ShapeFlat
(formato di trasferimento)
Procedure di
Caricamento
DBTR
Estratto del DBTR
Caricatore
ShapeToTable
© 2011 - Pelagatti Giuseppe
X
DBTL
Vantaggi e Svantaggi del
ShapeToTable
• Il caricamento diretto ShapeToTable degli ShapeFile estratti dal DBTR in
Tabelle relazionali presenta i seguenti vantaggi:
– permette di costruire un DBTL a costo praticamente nullo
– permette di avere un estrattore a costo praticamente nullo
– è comunque migliore di un caricamento diretto degli Shape di Produzione
• però ha anche le seguenti limitazioni.
– non è necessariamente ottimale rispetto a tutte le tecnologie di utilizzazione
per quanto riguarda le applicazioni e gli aggiornamenti
– in particolare, per utilizzare tecnologie OpenSource in aggiornamento
sarebbe opportuno rivedere la strutturazione di alcune classi e creare
procedure automatiche di aggiornamento delle geometrie derivate
© 2011 - Pelagatti Giuseppe