Gli strumenti della metodologia GeoUMLcentrointerregionale-gis.it/CATALOGUE/seminario_13... ·...

Seminario - “Gli strumenti della metodologia GeoUML: le sperimentazioni e le possibili applicazioni per le validazioni dei dati”

Roma, 13 ottobre 2011, presso l’Ufficio di Gabinetto di Roma della Regione Autonoma Friuli Venezia Giulia

Gli strumenti della metodologia

GeoUML

prof. Giuseppe Pelagatti

Politecnico di Milano



2

Struttura della presentazione

1. Il progetto «Metodologia GeoUML»

1.1 Aspetti fondamentali

1.2 Tappe del progetto

1.3 Risultati conseguiti

2. Confronti Internazionali (standard e

ricerca)

3. Applicazioni

Documentazione: SpatialDBgroup.polimi.it



3

1.1 Aspetti fondamentali

• una metodologia per la produzione e gestione dei Data Base

territoriali e per la loro integrazione in una Infrastruttura dei

Dati Territoriali (IIT o SDI)

• supportata da strumenti specifici

• sviluppata congiuntamente da CISIS e Polimi

• adottata dal Comitato per le regole tecniche sui dati territoriali

delle Pubbliche Amministrazioni per preparare:

– il Catalogo dei Dati territoriali – Specifiche di contenuto

per i DB Geotopografici (gdl2)

– il Catalogo dei Dati relativi alle reti di sottoservizi -

Specifiche di Contenuto per i DB delle Reti di Sottoservizi

(gdl8)



4

Schema Concettuale e modello

GeoUML

• lo Schema Concettuale (SC) costituisce il nucleo centrale di tutta la metodologia; uno SC costituisce una:

– definizione precisa del contenuto informativo di un DBT

– indipendente dalla tecnologia

• uno Schema Concettuale è la parte formale, strutturata secondo regole precise, di una Specifica di Contenuto, che aggiunge allo SC anche delle parti descrittive

• il Modello GeoUML:

– è un modello per la definizione di uno Schema Concettuale

– è basato sugli standard ISO TC211, ma li completa negli aspetti carenti

– considera come parte integrante e fondamentale di uno schema concettuale la definizione delle proprietà topologiche dell’informazione spaziale: Vincoli di Integrità Topologici



5

Strumenti della metodologia GeoUML

• Lo strumento fondamentale è il GeoUML Catalogue, la cui funzione è di gestire uno schema concettuale

• Una specifica gestita dal Catalogue non è un semplice documento, come le specifiche tradizionali, perchè può essere elaborata automaticamente

• L’elaborazione automatica di una specifica tramite GeoUML Catalogue e utile in due direzioni:

1. nella elaborazione dei dati conformi alle specifiche tramite strumenti guidati dalle specifiche (Schema Driven Tools)

– il GeoUML Validator, che verifica la conformità di un Dataset a una specifica, è uno Schema Driven Tool del GeoUML

2. nell’analisi e confronto tra specifiche diverse, in particolare nelle Infrastrutture dei dati territoriali (IIT o SDI)



6

Strumenti GeoUML

SC.scs

GeoUML

validator

Dataset

da validare

Messaggi

diagnostici

GeoUML

catalogue

Il formato scs:

uno schema

XML (XSD)

pubblicato

Questo file

contiene una

rappresentazione

XML dello SC



7

Quale conformità viene controllata? Occorre distinguere:

• Conformità Reale: la conformità reale riguarda la corrispondenza tra il contenuto informativo del Dataset e la porzione di Mondo Reale alla quale il Dataset si riferisce; gli elementi informativi e i relativi elementi descrittivi della SC determinano come tale corrispondenza debba essere valutata

La conformità reale non può essere verificata automaticamente collaudi a campione

• Conformità Intrinseca: la conformità intrinseca riguarda la consistenza dell’informazione contenuta nel Dataset; sia gli elementi informativi che i vincoli dello SC sono utilizzati per valutare la conformità intrinseca

La conformità intrinseca può essere valutata automaticamente in maniera esaustiva



8

Modello Implementativo

• Uno strumento che accede ai dati, come il Validator, deve conoscere, oltre allo SC, anche la struttura fisica dei dati (Schema fisico)

• Schema Fisico(SF) dipende dalla tecnologia, ad esempio:

– XSD per un file GML

– Create Table per Georelazionale SQL

– Struttura degli Shapefile

• Modello Implementativo (MI): è un insieme di Regole che permettono di generare un SF da un SC

• La struttura del Validator è progettata per limitare al minimo il costo dell’adattamento ad un nuovo MI

isolamento dei componenti che dipendono dal MI tramite una struttura normalizzata



9

Isolamento del MI nei tools

GeoUML Catalogue SCa

Mapping

Generator

MIx

SCa.scs

GeoUML Validator

Reader

per MIx Struttura

normalizzata

(PostGIS)

Controlli

dei vincoli

Dataset

D(a,x)

altri

Mapping

Generator

DB

delle

diagnosi



1.2 Tappe del progetto

• 5 dic 07: Bologna – presentazione del progetto «Lotto 2»

– Catalogue: uno strumento per la gestione di specifiche

– Generatore dello schema GML

• 23 set 08: Roma

– presentazione GeoUML Catalogue (con specifiche Intesa)

– prima proposta GeoUML Validator (su dataset GML)

– successivamente, a causa della non disponibilità di

dataset GML viene concordata una prima versione su MI

SQL_flat Oracle

• 4-6 set 09: Cremona – corso tecnico

– discussione delle problematiche di impiego del Catalogue

per il NC

– definizione dei concetti di «popolamento alle scale» e di

«aree collassabili» da introdurre nel Catalogue



Tappe del progetto

• dic 09: Catalogue disponibile con le estensioni per il NC

• apr 10: pubblicazione NC su sito CNIPA

• 9 nov 10: Brescia (ASITA)

– presentazione primo rilascio del Validator

– MI SQL_flat Oracle

– dati del Comune di Cremona

• giu 11: consegna MI Shape_Flat e Shape_Topo per le

produzioni sperimentali Veneto, Piemonte, Lazio, Umbria

• lug 11: consegna MI SQL_monogeometria (Postgis e Oracle)

per sperimentazione DBT Lazio

• lug – ott 11: primi risultati delle sperimentazioni

• in corso:

– correzione errori, completamenti di alcuni Reader

– stesura documentazione



1.3 Risultati Conseguiti

Strumenti realizzati •Catalogue

•Validator

•Mapping Generator e Reader per i seguenti MI:

– Shape_Flat

– Shape_Topo

– GML (versione revisionata rispetto al 2009)

– SQL_flat_Oracle

– SQL_monogeometria_PostGIS

– SQL_monogeometria_Oracle



13

Dimensioni del progetto Circa 7 anni/uomo di sviluppo + attività di studio e ricerca Linee di codice effettive misurate sui sistemi completati:

(escluse le numerose librerie di terze parti incorporate)

Catalogue (esclusi MI): 138316

Generatori di schema (6 MI): 27501

Totale: 165817

Validator: 104161

Reader di 3 MI (6 al completamento): 29592

Totale: 133753

Totale complessivo: 299570



14

Prestazioni

Misure relative alla sperimentazione

Veneto:

Totale record: 62143

Tempo di totale: 7 min 42 sec

Numero di query generate ed eseguite

• Controllo chiavi e univocità: 1118

• Controllo dei vincoli GeoUML: 2074



Documentazione prodotta Documenti di Specifica

• Il modello GeoUML (aprile 2008)

• Il MI Shape_Flat

• Il MI Shape_Topo

• Il MI SQL_Flat Oracle

• Il MI SQL_monogeometria

PostGIS

• Il MI SQL_monogeometria Oracle

• Il MI ESF_GML (versione 2011)

•

Guide all’Uso (da completare entro

2011)

• GeoUML Methodology and Tools –

Organizzazione complessiva

• Guida al modello GeoUML

• Guida all’uso del GeoUML

Catalogue

• Guida all’uso del GeoUML

Validator

• Guida ai MI di tipo flat

• Guida alla implementazione delle

proprietà geometriche del

GeoUML



Know How

Creazione di Know How relativamente a:

– GeoUML Tools

– DB topografici

– problemi di rappresentazione numerica del dato

– problemi di interscambio dei dati

Diffusione del Know How tramite:

– i corsi

– la collaborazione nelle sperimentazioni

– la collaborazione nel gruppo di lavoro tecnico



2. Confronti Internazionali (standard e

ricerca)

Nel progetto sono sempre stati applicati i

seguenti criteri:

• gli standard internazionali sono stati applicati

il più possibile, compatibilmente con gli

obiettivi della metodologia

• Le soluzioni adottate sono sempre state

confrontate con le ricerche su temi simili a

livello internazionale



18

Confronti con Standard Internazionali

• E’ doveroso porsi le seguenti domande

– Perchè definire un approccio e un modello originali?

– Non sono sufficienti gli standard e le relative tecnologie, in

particolare:

• Standard di Geomatica (ISO TC 211), che a loro volta

si basano su alcuni

• Standard informatici (UML e OCL) e relativi strumenti

CASE (Computer Aided Software Engineering)

• Risposta: pur volendo utilizzare gli standard e le tecnologie

disponibili ovunque possibile, è necessario superare 2

categorie di limitazioni:

– limiti a livello del modello modello GeoUML

– limiti a livello degli strumenti GeoUML tools



19

GeoUML è basato sugli standard

• uno Schema Concettuale GeoUML può essere trasformato in un Application Schema standard utilizzando delle regole precise

• tali regole sono definite nel documento

Il Modello GeoUML

Regole di Interpretazione delle Specifiche di Contenuto

per i Database Geotopografici

• tali regole costituiscono la definizione formale della semantica del GeoUML

• la produzione automatica di un Application Schema standard da uno Schema Concettuale è implementata nel GeoUML Catalogue

• anche la produzione automatica di un XSD per GML è basata sulle regole definite negli standard



20

Estrazione di un AS da uno schema GeoUML

(non disponibile nella versione attuale)

GeoUML_

Catalogue SC.xmi

CASE

(es: ARGO

UML)

Diagrammi

del AS

(in forma

grafica)



21

dal GeoUML catalogue al GML schema

(3 diversi percorsi possibili)

CASE

Tool

GeoUML

catalogue

ASgml_oriented.XMI

Encoding

Tool

l’ASgml_oriented

in forma di

diagrammi

UML

1

2 e 3

2

3

2 e 3

2 e 3

GML

Schema



22

Limiti degli standard per i fini del progetto

• Problemi del modello geometrico (necessità prevista anche da ISO di creare profili) tipi geometrici del modello GeoUML

• Inapplicabilità pratica (almeno allo stato attuale della tecnologia) del OCL per definire vincoli topologici vincoli topologici del modello GeoUML

• Livello di astrazione insufficiente per alcuni costrutti costrutti speciali del modello GeoUML (esempio: attributi a tratti)



23

Limiti del Modello Geometrico

• ISO definisce 2 modelli geometrici di interesse:

– Spatial Schema: è un modello di riferimento molto generale, rispetto al quale si prevede di “ritagliare” dei profili

– Simple Feature Model (SFM): è un profilo di Spatial Schema caratterizzato da:

• primitive solamente 2D

• interpolazione lineare

• Le tecnologie disponibili applicano SFM, ma generalmente prevedono

– la possibilità di introdurre una terza coordinata nei vertici

– tale coordinata non viene utilizzata nella valutazione delle relazioni topologiche (topologia planare)

– esempio: una intersezione tra due curve è valutata nel piano



24

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



25

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



26

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



27

Vincoli Topologici

• I vincoli sono trattati negli standard ISO TC211 semplicemente rimandando al linguaggio OCL (object constraint language) del UML, all’interno del quale dovrebbero essere invocate le funzioni topolgiche del modello geometrico

• in GeoUML è stato definito un formalismo apposito per definire vincoli di natura topologica, con le seguenti motivazioni:

– la valutazione automatica dei vincoli OCL, in particolare con l’inclusione di richiami a funzioni spaziali, è oggetto di sperimentazione in alcuni progetti di ricerca, ma non esiste una soluzione completa al problema

– l’uso di OCL con funzioni spaziali è molto difficile e improponibile ad utenti non specialisti di UML/OCL

– la generalità di OCL rende difficile estrarre dai vincoli topologici delle indicazioni per la strutturazione dei dati



28

Vincoli topologici in GeoUML

• i vincoli topologici sono delle “strutture prefabbricate” (template) di vincoli OCL, pertanto:

– i vincoli GeoUML possono essere trasformati in vincoli OCL

– le regole di tale trasformazione sono fornite nel documento citato, che ne definisce la semantica precisa

– i vincoli GeoUML sono definiti in modo da garantirne la implementabilità effettiva (come dimostrato dal GeoUML Validator)

– i vincoli GeoUML sono (relativamente al OCL) più comprensibili

– i vincoli GeoUML forniscono indicazioni per strutturare l’implementazione



29

Costrutti speciali

(esempio: Attributi a tratti) • I costrutti speciali hanno due tipi di motivazione.

– fornire dei costrutti utili per definire sinteticamente le proprietà dell’informazione

– in alcuni casi tale definizione sintetica evita di includere scelte implementative nello Schema Concettuale

• esempio Attributi a tratti: attributi il cui valore varia lungo una curva (es. la “sede” di un “elemento stradale”)

– il costrutto è sintetico e comodo da usare nella definizione dello Schema Concettuale

– il costrutto è definito formalmente in GeoUML come una funzione

– esistono due implementazioni completamente diverse di un ATT:

• l’implementazione strutturale (“pezzettini” di curva)

• l’implementazione tramite ascissa curvilinea



30

Limiti a livello degli strumenti

• Limiti degli Strumenti CASE classici

– non gestiscono le caratteristiche del modello GeoUML

– permettono la generazione della struttura fisica, ma non

supportano direttamente strumenti operanti sui dati

guidati dallo schema

• GeoUML tools

– il Catalogue gestisce il modello GeoUML

– permette la generazione della struttura fisica e il

salvataggio dell’informazione di mapping, che è a sua

volta usabile dai GeoUML Tools

• NB: questo è possibile perchè siamo in un contesto più

specializzato e meno generale dei CASE standard



31

CASE generali verso GeoUML tools

CASE tool

classico

(Modello

UML)

Data Base

(tecnologia

standard)

generatore

di schema

fisico

GeoUML

Catalogue

(Modello

GeoUML)

Data Base

Territoriale

(tecnologia

standard)

GeoUML

Validator

(o altri tool)

(si adattano alle

variazioni di SC

si specializzano

per diversi MI)

Applicazioni

sul

Data Base

(incorporano

lo schema

fisico)

Schema fisico Schema fisico



32

Confronti con la ricerca internazionale:

1) il modello concettuale

• Il modello GeoUML è stato presentato a livello concettuale all’epoca della sua definizione e adozione nel progetto «IntesaGIS»:

– GeoUML: a Geographic Conceptual Model Defined through Specialization of ISO TC 211 Standards, Atti di "10th EC-GI&GIS Workshop", Warsaw, Poland, 23-25 June, 2004.

• Le problematiche specifiche relative alle tipologie di vincoli spaziali sono state pubblicate in:

– Modelling Spatial Whole-Part Relationships using an ISO-TC211 conformant approach, «Information and Software Technology», vol.48, 2006, pp.1095-1103.

– An ISO TC 211 Conformant Approach to Model Spatial Integrity Constraints in the Conceptual Design of Geographical Databases, in Lecture Notes in Computer Science a cura di John F. Roddick et al., Berlin/Heidelberg, Springer, 2006, pp. 100-109.



33

Confronti con la ricerca internazionale

2) L’architettura dei tools • L’architettura dei GeoUML tools è stata

presentata in – From the Conceptual Design of Spatial Constraints to

their Implementation in Real Systems, Atti di "17th ACM SIGSPATIAL International Conference on Advances in GIS", Seattle, Washington, USA, Nov. 4-6, 2009, pp. 448-451.

• L’insieme dei modelli implementativi inseriti nell’architettura è stata presentata in: – Validation of geographical datasets against spatial

constraints at conceptual level, atti di UDMS 2011, Delft

• Esiste un’attività di confronto su questi temi con l’università di Delft e l’università di Stuttgart; in particolare si vogliono esplorare: – estensioni al 3D

– rapporto con CityGML



34

3) Applicazioni

Modalità di distribuzione

• Catalogue è

– distribuito a tutti, previa registrazione, nella

versione Viewer

– distribuito agli enti abilitati dal CISIS nella

versione Editor

• Validator verrà (dettagli ancora da definire)

– distribuito agli enti abilitati dal CISIS nella

versione completa

– questi enti potranno distribuirlo a altri (esempio

ditte) in versione «chiusa», cioè con la SC

bloccata



35

Sperimentazione iniziale nel 2009- 2010

(presso il Comune di Cremona)

• sperimentazione estensiva con il Comune di Cremona

• il Comune aveva già un DB topografico e un SIT basato su tale DB

• è stata definita una nuova specifica concettuale tramite Catalogue, conforme al National Core e al capitolato di fornitura attuale della RL

• è stato applicato il Generatore dello Schema fisico del MI ESF-SQL-flat (versione per ORACLE)

• il modello fisico generato è stato adattato alle convenzioni specifiche del Comune

• sono state definite delle procedure di conversione dal vecchio al nuovo DBT

• è stato utilizzato il Validator per controllare il nuovo DBT

• sono state definite delle Views sul database nuovo per supportare il funzionamento delle precedenti procedure applicative



36

Uso di Catalogue e Validator nelle nuove

forniture

• Capitolato di fornitura - Sezione contenuti e struttura consiste in:

– SC prodotta dal Catalogue

– schema fisico e schema di mapping prodotti dal Mapping Generator in base al MI di fornitura scelto

• per ridurre l’impatto sulle ditte è opportuno concordare pochi MI di fornitura adottati da tutte le regioni che applicano la metodologia

• il controllo di conformità intrinseca della fornitura avviene tramite Validator – tale controllo si affianca (dovrebbe precedere) e supporta il tradizionale collaudo di conformità reale



37

Uso di Catalogue e Validator nella

implementazione dei DBT regionali

• definizione dello schema: I MI di tipo SQL supportano questa attività producendo direttamente lo schema fisico del DB

– tali schemi sono adattabili e flessibili per adattarsi alle esigenze di uno specifico contesto

• caricamento: la filiera produzione dei dati caricamento in DB è particolarmente facilitata dai seguenti aspetti:

– le strutture adottate nei MI di produzione sono molto allineate alle strutture adottate nei MI dei DB (questo aspetto è più o meno forte in base agli specifici MI scelti)

– la qualità strutturale dei dati prodotti e collaudati tramite Validator rende gli Shapefile di produzione caricabili con poche difficoltà nei DB



38

Considerazioni finali

La effettiva applicabilità degli strumenti verrà ora

analizzata nei resoconti e dimostrazioni delle

sperimentazioni effettuate da alcune Regioni

Teniamo presente che tali sperimentazioni

mettono in gioco non solo gli strumenti ma

anche le scelte del National Core

Pertanto, è necessario considerarle

distinguendo gli aspetti dovuti a queste 2

componenti

Sia gli strumenti che il NC possono essere

migliorati

Gli strumenti della metodologia GeoUMLcentrointerregionale-gis.it/CATALOGUE/seminario_13... ·...

Documents

Transcript of Gli strumenti della metodologia GeoUMLcentrointerregionale-gis.it/CATALOGUE/seminario_13... ·...