1. Giuseppe Pelagatti pelagatt@elet.polimi.it 8 giugno 2011 Il modello GeoUML e gli strumenti Catalogue e Validator nell’Interscambio tra DBTL e DBTR

2. © 2011 - Pelagatti Giuseppe 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 2

3. © 2011 - Pelagatti Giuseppe 1)Ruolo degli strumenti Catalogue e Validator nella IIT DBTL di un gestore Gx ESTRATTORE DBTL di un gestore Gy ESTRATTORE DbTR Formato di interscambio Aggiornamenti locali Aggiornamenti locali porzione x porzione y Lotto di Aggiornamento Interfaccia Dati Regolata (si appoggia sui protocolli di comunicazione) tecnologia locale (diversa da quella regionale) contenuti locali (includono quelli condivisi)

4. © 2011 - Pelagatti Giuseppe 4 GeoUML catalogue Schema Concettuale del DBTR (definisce i contenuti condivisi della IIT) GeoUML catalogue

5. © 2011 - Pelagatti Giuseppe 5 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

6. © 2011 - Pelagatti Giuseppe 6 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

7. © 2011 - Pelagatti Giuseppe Schema Concettuale nella IIT DBTL di un gestore Gx DBTR Lotto di Aggiornamento Schema Concettuale (definizione dei contenuti condivisi) Shape_Flat (mapping manuale)

8. © 2011 - Pelagatti Giuseppe 8 GeoUML Validator SC.scs GeoUML validator Dataset da validare Messaggi diagnostici GeoUML catalogue

9. © 2011 - Pelagatti Giuseppe 9 Validator e Lotto di Aggiornamento GeoUML Catalogue SC DBTR Mapping Generator Shape_Flat SC DBTR.scs GeoUML Validator Reader per Shape_Flat Controlli (geometrie, Vincoli) Lotto di Aggiornamento (formato Shape_Flat) DB delle diagnosi Query e Reports

10. © 2011 - Pelagatti Giuseppe Validator nell’aggiornamento della IIT DBTL di un gestore DBTR Lotto di Aggiornamento (Shape_Flat) Schema Concettuale (contenuti condivisi e vincoli) Validator (presso Gestore) Validator (presso RL) Procedure di controllo alternative o complementari trasferimento

11. © 2011 - Pelagatti Giuseppe 11 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

12. © 2011 - Pelagatti Giuseppe 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

13. © 2011 - Pelagatti Giuseppe 13 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

14. © 2011 - Pelagatti Giuseppe 14 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

15. © 2011 - Pelagatti Giuseppe 15 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.superficie S.B3D polygonZ 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 P.PLN P Q

16. © 2011 - Pelagatti Giuseppe 16 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.

17. © 2011 - Pelagatti Giuseppe 17 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 )

18. © 2011 - Pelagatti Giuseppe 18 Esempi di relazioni topologiche overlap

19. © 2011 - Pelagatti Giuseppe 19 Esempi di relazioni topologiche

20. © 2011 - Pelagatti Giuseppe 20 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

21. © 2011 - Pelagatti Giuseppe 21 Accesso esterno diretto Accesso esterno indiretto Accesso interno A C B Pertinenza degli edifici B e C Elementi stradali posizioneaccessibilità V3V1 V2 V1 Esempi di geometrie valide

22. © 2011 - Pelagatti Giuseppe 22 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

23. © 2011 - Pelagatti Giuseppe 23 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

24. © 2011 - Pelagatti Giuseppe 24 Esempio Ipotesi: esiste il vincolo Rosso (TC) Blu Questa situazione NON lo soddisfa Questa situazione lo soddisfa Questa relazione è TC, la geometria vincolata A-B è identica nei 2 poligoni (geometria vincolata) A B Questa relazione è OV,

25. © 2011 - Pelagatti Giuseppe 25 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

26. © 2011 - Pelagatti Giuseppe 26 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

27. © 2011 - Pelagatti Giuseppe 27 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

28. © 2011 - Pelagatti Giuseppe 28 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

29. © 2011 - Pelagatti Giuseppe 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 29

30. © 2011 - Pelagatti Giuseppe 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)

31. © 2011 - Pelagatti Giuseppe Creazione di un nuovo DBTL tramite ShapeToTable DBTR DBTL Estratto del DBTR ShapeFlat (formato di trasferimento) Caricatore ShapeToTable Procedure di Caricamento Shapefiles di produzione X

32. © 2011 - Pelagatti Giuseppe 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