Vortrag Titelseiten · I modelli, il trasferimento dei dati, e l’interoperabilità nei GIS zione...

Eidgenössische Technische Hochschule Zürich

Institut für Geodäsie und Photogrammetrie

Bericht

305

Presentations of the 3rd Meeting of the Comitato scientifico italo-svizzero

per la geoinformazione (CSISGI)

Les Marécottes, 15.-17. Juni 2008

Herausgeber:

Prof. Dr. A. Carosio, ETHZ Prof. Dr. F. Golay, EPFL

Prof. Dr. M. Brovelli, POLIMI

Juni 2008

IGP Bericht Nr. 305 Presentations of the 3rd Meeting of the Prof. Dr. Alessandro Carosio, ETHZ Comitato scientifico italo-svizzero Stefan Henrich, ETHZ per la geoinformazione (CSISGI) Peter Staub, ETHZ Les Marécottes Prof. Dr. François Golay, EPFL

Eduardo Camacho-Huebner, EPFL Cláudio Carneiro, EPFL

Jens Ingensand, EPFL Michaël Kalbermatten, EPFL

Prof. Dr. Maria Brovelli, POLIMI Marco Negretti, POLIMI Eugenio Realini, POLIMI Milan Antonovic, SUPSI

Dr. Massimiliano Cannata, SUPSI Prof. Dr. Rossella Nocera, UNIMOL

© 2008 Institut für Geodäsie und Photogrammetrie an der Eidg. Technischen Hochschule Zürich Wolfgang-Pauli-Strasse 15 CH-8093 Zürich Alle Rechte vorbehalten ISBN 978-3-906467-77-1

Content

Session I: Interoperability as a precondition for the realisation of spatial data infrastructures

Alessandro Carosio, Rossella Nocera, Hans Rudolf Gnägi, Andreas Morf and Peter Staub: I modelli, il trasferimento dei dati, e l’interoperabilità nei GIS 5

Peter Staub: Spatial data infrastructures and interoperability 35

Stefan Henrich: Prerequisites for interoperability 41

Peter Staub: Semantic interoperability for INSPIRE: the Swiss-German solution – research project “Model-Driven WFS” 57

Sesion II: Other aspects of interoperability

Eduardo Camacho-Huebner: Ontologies evolution: from social sciences’ needs to interop opportunities 77

Massimiliano Cannata: Institute of Earth Science: current and future activities at the geomatics division 89

Milan Antonovic: Sensor observation service (SOS): insights and implementation 109

Session III: Mobile GIS and infrastructure

Marco Negretti: ICAD-GEO: studio di fattibilità per la realizzazione di un progetto per la realizzazione di una "infrastruttura per la cooperazione applicativa dei dati geografici" 125

Maria Brovelli: WebGIS & context aware mobile GIS 137

Eugenio Realini: slaxGIS – a GIS-oriented live USB system 147

Session IV: Added value of the 3rd dimension through enriched semantics

François Golay: Update on LASIG’s research activities. Some more semantics into the 3rd D: some insights and questions 157

Cláudio Carneiro: Matching 3D city models and urban indicators to users’ needs 165

Michaël Kalbermatten: Landscape characterization using wavelet detail coefficients 185

Jens Ingensand: 3D web interfaces to the “Patrouille des Glaciers” race 213

1

Session I – Interoperability as a precondition for the realisation of spatial data infrastructures

I modelli, il trasferimento dei dati, e l’interoperabilità nei GIS

Prof. Dr. Alessandro Carosio 1

Prof. Dr. Rossella Nocera 2

Hans Rudolf Gnägi 1

Andreas Morf 1

Peter Staub 1

1 ETH Zürich, Institut für Geodäsie und Photogrammetrie Gruppe GIS und Fehlertheorie

2 Università degli Studi del Molise, Sede di Termoli

5

A. Carosio, ETHZ / R. Nocera, UNIMOL / H.R. Gnägi, A. Morf, P. Staub, ETHZ – I modelli, il trasferimento dei dati, e l’interoperabilità nei GIS

I modelli, il trasferimento dei dati,

e l’interoperabilità nei GIS

Alessandro Carosio*, Rossella Nocera**

Hans Rudolf Gnägi*, Andreas Morf*, Peter Staub*

* Institut für Geodäsie und Photogrammetrie, ETH Zürich, Svizzera

* * Università degli Studi del Molise, Sede di Termoli, Italia

La necessità di scambio di dati geografici Uno dei beni principali di una società è il relativo ambiente e per prendere le decisioni relative all’ ambiente, occorre disporre di buone informazioni geografiche, ossia di geodati che descrivono direttamente o indirettamente (tramite un’informazione di posizione) le caratteristiche ed i fenomeni ambientali. Negli ultimi trenta anni la raccolta di geodati è stata influenzata notevolmente dagli sviluppi dell’informatica, dalle rivoluzionarie tecniche di rilevamento e dalle infrastrutture di telecomunicazione. La quantità di dati disponibili è aumentata velocemente a causa di tali progressi tecnologici e del numero crescente di persone e di istituzioni che usano i geodati. Oggigiorno tutte le grandi e piccole organizzazioni, sia private che pubbliche, dispongono di grandi quantità di dati geografici e nasce la necessità di sfruttare in comune questo patrimonio.

In molti paesi si realizzano infrastrutture nazionali di dati per usare in comune i dati esistenti. Ma attualmente perfino i confini nazionali sembrano stretti. Si presenta ben chiara la necessità di disporre

GIS GISGIS

Fig. 1 Molteplicità d’uso e necessità di scambi di dati

7


di sistemi interagenti. Negli ultimi anni si lavora a livello europeo e mondiale per creare norme tecniche volte a fornire le direttive per attuare tali soluzioni.

Fig. 2 Infrastrutture nazionali (NGDI), elementi fondamentali In tale contesto qualsiasi sistema informativo geografico non può essere considerato efficiente se non prevede la soluzione di questioni riguardanti lo scambio dei dati e soprattutto l’offerta di servizi basati su più sistemi interagenti. Nel campo dei GIS l’aspetto dello scambio dei dati ha assunto significati diversi negli anni. Inizialmente esisteva l’esigenza di scambiare solo dati all’interno di ambienti omogenei (stesso fornitore, quindi formati proprietari). Nel tempo nasce la necessità di scambiare dati tra produttori diversi ed è cosi che si introducono i concetti di formati standard di interscambio, di trasferimento di dati basato su modello e di interoperabilità (secondo i concetti di OGC). L’evoluzione si è quindi spostata da soluzioni più semplici quali l’utilizzo di convertitori di dati e formati standard fino a soluzioni più evolute che permettono l’utilizzo in parallelo di diversi GIS eterogenei senza spostare i dati geografici del sistema. Soluzioni per lo scambio dei dati geografici L’uso generalizzato dell’informazione geografica richiede quale primo elemento norme per regolare il trasferimento dei dati tra sistemi GIS diversi. a) Trasferimento tra sistemi uguali o con formati standard

Una necessità importante consiste nel trasferimento di dati da un’applicazione ad un’altra realizzata con lo stesso software. I GIS dispongono fondamentalmente di funzioni per l’importazione e l’esportazione di dati geografici tramite files. I formati utilizzati sono compatibili esclusivamente con uno specifico software GIS (formato proprietario) e richiedono la medesima struttura-dati per i files da scambiare. Con l’aumento delle tecnologie GIS e delle persone e organizzazioni coinvolte nel settore nasce l’esigenza di scambiare informazioni geografiche anche tra sistemi di diversi produttori. Primi tentativi di soluzione hanno portato alla realizzazione di formati standard. Premessa per la defini-

Dati geospaziali Metadati

Infrastrutturetecniche

Basi giuridicheDirettive e Standards

Formazione e Ricerca

Geo-Servizi dibase

Politicatariffaria

Coordinamentoe rete di contatto

NGDINGDI


Infrastrutturetecniche



Geo-Servizi dibase

Politicatariffaria

Coordinamentoe rete di contatto

NGDINGDI

8


zione di un formato standard è la definizione anticipata dei contenuti. Ciò si verifica solo in quelle applicazioni in cui le informazioni da elaborare sono decise in modo unitario per tutti i sistemi.

Fig. 3 Trasferimento dei dati con formati predefiniti

b) Trasferimento basato su modello

Le diverse esigenze e la varietà delle applicazioni e dei sistemi rendono poco realistica la definizio-ne di formati unitari. Occorrono altre soluzioni per scambiare dati a struttura variabile; una soluzio-ne appropriata è rappresentata dalle procedure basate sul modello anziché dai formati unitari. Attualmente i GIS in uso offrono all’utente una struttura prestabilita per i dati geometrici e la possibilità di definire, secondo le diverse esigenze dell’utente, i contenuti tematici. Il sistema costruisce poi le diverse classi di entità (tipicamente tabelle relazionali in un DB). Lo stesso principio può anche essere utilizzato per organizzare lo scambio di dati in modo flessibile: si descrive la struttura dei dati che si intende trasferire, e da questa descrizione è possibile ricavare un formato per questi dati. A questo scopo sono necessarie due componenti: in primo luogo un linguaggio standardizzato per la descrizione dei dati per definire in modo univoco e consistente la struttura dei dati da trasferire, e in secondo luogo una procedura regolamentata per ricavare un formato dalla struttura dei dati.

Fig. 4 Trasferimento dei dati basato sul modello

GIS 1 GIS 2GIS 1GIS 1 GIS 2GIS 2

GIS 1GIS 1GIS 1

9


Le norme ISO hanno definito come standard il metodo di trasferimento dei dati basato sul modello. L’ISO ha deciso solo un formalismo grafico per la descrizione della Struttura dei dati: UML. Tale tecnologia offre opportunità anche in altri settori: GIS moderni permettono l‘implementazione del modello direttamente dallo schema concettuale.

Fig. 5 ArcGIS: implementazione del modello da uno schema UML

c) Interoperabilità

Le diverse soluzioni fin qui proposte hanno come obbiettivo il trasferimento di dati da un sistema all’altro. È invece possibile concepire sistemi di comunicazione che funzionano senza spostare i dati geografici del sistema. Questa soluzione è particolarmente interessante, quando sono necessarie solamente semplici elaborazioni delle informazioni, p. es. la rappresentazione grafica di una parte dei dati (web mapping services, wms), oppure l’elenco di determinati oggetti o caratteristiche (web feature services, wfs). In questi casi è più facile standardizzare i comandi e i risultati dell’elaborazione, piuttosto che i dati di base. In questo caso si parla di interoperabilità, ossia utilizzo parallelo di diversi GIS, mediante lo scambio dei comandi (richieste, indicazioni di elaborazione) e dei risultati. L’Open Geospatial Consortium (OGC) promuove lo sviluppo di questa tecnica. Grazie alla partecipazione delle aziende leader a livello internazionale (ESRI, Intergraph, Siemens, Microsoft, ecc.) ed all’incorporazione di università e istituti di ricerca, l’OCG ha ottenuto una vasta risonanza e ha creato grandi aspettative. I vantaggi del concetto di interoperabilità sono evidenti: il concetto di gestione dei dati può essere molto diverso nei sistemi in comunicazione. Il sistema che invia una richiesta non deve assolutamente conoscere nulla sull’organizzazione interna dei dati nel sistema che li fornisce: i sistemi non trasmettono che parti del proprio contenuto e i dati originali restano sotto il proprio controllo (diritti d’autore, proprietà intellettuale). Esiste, inoltre, un grande vantaggio per i produttori di software GIS: i clienti non possono cambiare facilmente il fornitore. I limiti sono pure chiari: la diversità delle richieste standardizzate e delle forme di risposta non può essere troppo grande. Se le interoperazioni desiderate diventano troppo complesse, troppo diverse, o troppo numerose, lo scambio diretto dei dati diventa più semplice e vantaggioso rispetto alla standardizzazione delle operazioni.

10


Fig. 6 Interoperabilità (normalizzazione Domanda-Risposta)

Limiti e prospettive Da quanto detto fin qui, nasce spontanea la domanda: Sarà possibile realizzare il sogno di trasferire dati geografici tra sistemi completamente diversi o inviare loro richieste ottenendo risposta in modo totalmente automatico? Si affermerà l’interoperabilità o piuttosto i metodi che trasferiscono effettivamente i dati? A quest’ultima domanda si può senz’altro rispondere che entrambe le soluzioni sono necessarie: esse non sono alternative, ma sono soluzioni complementari. Per il problema del trasferimento dei dati in modo automatico si deve, purtroppo, riconoscere l’impossibilità ad avere un metodo che sia completamente automatico, infatti esiste un ostacolo teorico insuperabile: La non univocità della semantica. Elementi uguali (entità, oggetti, attributi) possono essere denominati in modo diverso (per es. case o edifici, abbreviazioni, lingue straniere, diverse istruzioni al rilevamento ecc.). Denominazioni identiche possono avere significato diverso. Occorre quindi rassegnarsi al fatto che in strutture dati di diversa origine una ricostruzione automatica della semantica è impossibile.

Fig. 7 La semantica non è ricostruibile automaticamente

GIS 1

GIS 2

GIS 3

GIS 4

domanda

Risposta

Risposta

GIS 1GIS 1

GIS 2GIS 2

GIS 3

GIS 4

domanda

Risposta

Risposta

Rete elettrica Cavi elettrici

TubazioniAcquedotto

annodia-metro

dia-metro

Tipo

dia-metro

Anno costr.

Anno costr.

acquagas

acqua Rete distr. gas


TubazioniAcquedotto

annodia-metro

dia-metro

Tipo

dia-metro

Anno costr.

Anno costr.

acquagas



TubazioniAcquedotto

annodia-metro

dia-metro

Tipo

dia-metro

Anno costr.

Anno costr.

acquagas


11


Per mettere in relazione entità e attributi occorrono informazioni supplementari, quindi la semantica della descrizione dei dati non può essere standardizzata in un settore di attività lasciato alla libera iniziativa. Le relazioni tra i sistemi devono essere decise inizialmente in base ad un’analisi interpretativa di un esperto, a richieste presso i responsabili e a consultazione di metadati. In seguito è possibile eseguire la trasformazione semantica.

Fig. 8 L’identificazione delle relazioni tra i modelli richiedono l’intervento di un esperto Tuttavia, per sistemi federati (organizzati con regole comuni) sarà possibile, in settori specifici, sviluppare le ontologie che descrivono la semantica di più sistemi permettendo lo sviluppo di moduli di trasformazione automatici (agenti). Schemi diversi possono coesistere, se collegati da un'ontologia sufficientemente generale.

Fig. 9 Trasferimento dei dati basato sul modello

ontologiaontologia

Age

nti

Age

nti

Age

nti

Age

nti

ontologiaontologia

Age

nti

Age

nti

Age

nti

Age

nti

12


Per questo occorre analizzare, studiare, articolare il contenuto indipendentemente dal modo in cui è rappresentato; occorre lavorare con il contenuto in quanto tale, l’essere in quanto essere... ecco che emerge cosi la dimensione ontologica, in senso filosofico. L’ontologia nasce come antica riflessione dell'uomo sulla natura del mondo e delle cose, ma negli ultimi venti anni si sono registrate nuove e impreviste relazioni tra l’ontologia filosofica e campi applicativi che vanno dalle tecnologie dell’informazione alle scienze sociali. Anche nei sistemi informativi rappresenta una dimensione nuova di studio e di ricerca. Le trasformazioni semantiche In settori che si sono sviluppati autonomamente una standardizzazione dei concetti e della terminologia non può essere realizzata a posteriori e anche lo sviluppo di procedimenti basati su ontologie in senso filosofico ha poca probabilità di una realizzazione a breve termine. GIS sviluppati autonomamente sono la regola in progetti nazionali, quando i dati contenuti sono stati raccolti in precedenza da istituzioni regionali o comunali o da privati. Analogamente troviamo a livello europeo GIS indipendenti (p.es. INSPIRE) quando si vogliono di integrare informazioni acquisite e gestite autonomamente dagli stati membri. Per risolvere in un quadro operativo problemi di questo tipo con investimenti ragionevoli e a breve termine stanno per essere realizzate soluzioni informatiche basate sulla definizione a livello concettuale di trasformazioni semantiche tra modelli diversi. Tali trasformazioni devono essere descritte la prima volta in modo esplicito da personale esperto in base a tutte le conoscenze disponibili. Per definire la trasformazione occorre un linguaggio formale interpretabile da software che consenta di derivare automaticamente la procedura di trasformazione. Tale linguaggio proposto in un progetto di ricerca del Politecnico di Zurigo può avere la forma di un linguaggio testuale (simile a INTERLIS) o avere una presentazione grafica (simile a UML). Si parla in questo caso di UMLT. Descritta la trasformazione sulla base del modello origine e del modello obiettivo un compilatore determina le operazioni di trasformazione tra il formato di scambio per il modello origine e il formato relativo al modello obiettivo. Un prototipo di questa trasformazione dimostra la realizzabilità di questa procedura, che ha suscitato interesse nelle istituzioni responsabili della messa in opera di INSPIRE. Soprattutto in Germania, Austria e Svizzera.

13


CSL : Conceptual schema language DM-A o -Z : Modello dei dati dell sistema A a livello concettuale TF-A o -Z : Formato di trasferimento per i dati del sistema A o Z Model Mapping : Descrizione della trasformazione semantica Data Transformation : Operazioni eseguibili della trasformazione

Fig. 10 La trasformazione semantica

L’interoperabilità semantica Lo stesso problema si pone, quando si utilizzano gli standard dell’interoperabilità di OGC. Gli standard OGC sono solo definiti per l’interoperabilità sintattica. Ciò significa che per inviare una richiesta occorre conoscere la terminologia (nomi di attributi, classi di entità, sistema di riferimento ecc.) del sistema interrogato. Sul piano europeo nella migliore delle ipotesi occorre confrontarsi con decine di modelli e conoscerne i dettagli per inviare richieste d’informazione. Molto più semplice sarebbe poter inviare le richieste basandosi sul proprio modello o ev. su un modello di riferimento lasciando al sistema il compito di tradurre le richieste nei modelli dei sistemi interrogati per ottenere risposte tradotte nel linguaggio del proprio modello (interoperabilità semantica).

Fig. 11 L’interoperabilità semantica

14


Per realizzare l’idea dell’interoperabilità semantica è stata realizzata una piattaforma sperimentale nel quadro di una cooperazione multinazionale tra il “Bundesamt für Kartographie und Geodäsie” tedesco, l’Ufficio federale di topografia svizzero, il Politecnico di Monaco e il Politecnico di Zurigo. A tale progetto sono interessati e collaborano anche partner italiani (Politecnico di Milano, Università del Molise) e austriaci (TU Graz). Il concetto base è la creazione di un WFS (standard OGC) basato sul modello (mdWFS) mediante il quale le richieste sono tradotte o dal sistema richiedente (client) o dal sistema interrogato (source). Anche in questo modo di procedere la prima volta occorre definire con un linguaggio adatto (p.es. UMLT) la trasformazione tra un modello e l’altro. La definizione rimane a disposizione per richieste ulteriori.

Fig. 12 Il WFS basato sul modello (mdWFS) Le prime esperienze con il prototipo del mdWFS sono incoraggianti. Il progetto iniziale ha potuto essere prolungato per creare le premesse di un’integrazione di componenti informatiche con larga diffusione (Oracle DB, FME ecc.). Trattative con partner interessati sono in corso per l’implementazione del procedimento in software commerciali.

15


Bibliografia Carosio A. and Nocera R.: Il trasferimento dei dati, I metadi, I modelli e l’interoperabilità nei GIS. Atti

della 8a Conferenza Nazionale delle Associazioni per le Informazioni Territoriali e Ambientali, Roma, 2004.

Donaubauer A., Staub P., Straub F. and Fichtinger A.: Web-basierte Modelltransformation – eine Lösung für INSPIRE? GIS Zeitschrift für Geoinformatik, 13(2):26—33, 2008.

Donaubauer A., Fichtiner A., Schilcher M., Straub F., Carosio A., Gnägi H.R., Morf A. and Staub P.: Grenzübergreifende Web-GIS Lösungen. GIS Zeitschrift für Geoinformatik, 11(9):29—34, 2006.

Dorfschmid J., Brawer S.: La modelisation de donnees a reference spatiale. COSIG c/o swisstopo, CH-Wabern

Gnägi H.R.: INTERLIS KURS I und II. ETH Zürich, 2008.

KOGIS: INTERLIS 2 Reference manual. Online www.interlis.ch/interlis2/download_e.php.

Scott K.: UML Explained. Addison-Wesley.

Staub P.: A Model-Driven Web Feature Service for Enhanced Semantic Interoperability. OSGeo Journal, 1(3):43—50, 2007.

Staub P., Gnägi H.R. and Morf A.: Semantic Interoperability through the Definition of Conceptual Model Transformations. Transactions in GIS, 12(2):193—207, 2008.

16

A. Carosio, ETHZ / R. Nocera, UNIMOL / H.R. Gnägi, A. Morf, P. Staub, ETHZ – I modelli, il trasferimentodei dati, e l’interoperabilità nei GIS

I modelli , il trasferimento dei dati, e

l’interoperabilità nei GIS

Alessandro Carosio, Rossella Nocera Hans Ruedi Gnägi, Andreas Morf,Peter Staub

Institut für Geodäsie und Photogrammetrie, ETH Zürich

Oggi disponiamo di grandi quantità di dati geografici in forma digitale

…molte organizzazioni lavorano con tali dati.

Dobbiamo sfruttare in comune questo patrimonio

Arbeitsplatz 1

GIS 2 GIS 3GIS 1

Arbeitsplatz 2

Arbeitsplatz Arbeitsplatz

Ufficio ADitta 2Ditta 1

patrimonio

17


Una buona idea:NGDI


Infrastrutture tecniche



Geo-Servizi di base

Politica tariffaria

Coordinamento e rete di contatto

In molti paesi si realizzano infrastrutture nazionali di dati Per usare in comune i dati esistenti. Ma attualmente perfino i confini nazionali sembrano stretti :

Progetti internazionali in numero sempre maggiore ne sono la prova..Esempi: INSPIRE, Molti progetti INTEREG ecc.

Si presenta ben chiara la necessità di disporre di sistemi interagenti.Negli ultimi anni si lavora a livello europeo e mondiale per creare norme tecniche volte a fornire le direttive per attuare tali soluzioni.

L’uso generalizzato dell’informazione geografica richiede quale primo elemento norme per regolare il trasferimento dei dati tra sistemi GIS diversi e per renderli interoperabili.

Dati geospaziali Metadati Geo-Servizi di base

NGDI

Il trasferimento e l’interoperabilità dei dati è una funzione centrale per ogni GIS e l’uso efficiente di un GIS non può trascurare le soluzioni riguardanti lo scambio dei dati (tema della presentazione).

Infrastrutture tecniche



Politica tariffaria

Coordinamento e rete di contatto

18


I primi Sistemi inormativi geografici furono realizzati per soddisfare le esigenze di un solo utente

GIS 3

GIS 1

A b it l t

Ufficio A

Ditta 2

Arbeitsplatz GIS 2Arbeitsplatz

Arbeitsplatz

Arbeitsplatz

Ditta 1

GIS 1 GIS 2

Esigenza fondamentale:

Occorrono sistemi interagenti.

19


GIS 1 GIS 2

Sul piano nazionale e in organizzazioni internationali (Europa, Mondo) si lavora alla definizione di norme tecniche che permettano di realizzare sistemi interagenti. Occorrono norme per l‘interoperabilità e per il trasferimento die dati tra sistemi di origine diversa e con modelli die dati diversi.

+ DIN, AFNOR,ÖN, UNI, BS, …

GISGIS

GIS interagenti possono essere realizzati a diversilivelli di funzionalità

Trasferimento dei dati

Interoperabilita‘

20


GISGIS


• Trasferimento dei dati tra sistemi uguali

• Trasferimento dei dati con Formati StandardTrasferimento dei dati

• Metodi di trasferimento dei dati basati sul modello

• Interoperabilità (OGC = Open Geospatial Consortium)

In precedenza: Open GIS Consortium

Interoperabilita‘

GISGIS


• Trasferimento dei dati tra sistemi uguali

• Trasferimento dei dati con Formati StandardTrasferimento dei dati

• Metodi di trasferimento dei dati basati sul modello

• Interoperabilità (OGC = Open Geospatial Consortium)

In precedenza: Open GIS Consortium

Interoperabilita‘

21


GIS

3. Trasferimento basato sul modello

i dati geografici sono trasmessi in due parti:

Dapprima si invia la descrizione della struttura dati (modello concettuale)

Poi seguono i dati in un formato che viene derivato automaticamente dalla descrizione della struttura dei dati.

Cosa occorre:

1. linguaggio standard per la descrizione dei dati a livello concettuale per

3. Trasferimento basato sul modello (seguito)

definire in modo univoco e consistente la struttura dei dati da trasferire

2. Una procedura regolamentata per ricavare il formato di trasferimento dalla struttura dei dati

Derivazione del formato

22


Le norme ISO hanno definito come standard il metodo di trasferimento dei dati basato sul modello.

3. Trasferimento basato sul modello (seguito)

L’ ISO ha deciso solo un formalismo grafico per la descrizione della Struttura dei Dati: UML .

Un linguaggio testuale che possa essere interpretato automaticamente è previsto, sono state definite le sue caratteristiche, ma non è stata presa una decisione in merito (Possibile soluzione: Standard svizzero INTERLIS)( )


Lo standard svizzero INTERLIS

Realizzazione degli Standard ISO (TC 211) non solo per il trasferimento dei datip

23






24





UML INTERLIS 2 Formato di trasferimento XML

Formato basato su GML è in preparazione

25



UML INTERLIS 2 formato di trasferimento XML

formato GML (GML è ancora in fase di sviluppo)

Tale tecnologia offre opportunità anche in altri settori

• GIS Moderni permettono l‘implementazione del modello direttamente dallo schema concettuale:

ArcGIS da uno schema in UML (prodotto con Microsoft Visio)

Geo Media (Intergraph) da INTERLIS (per il mercato svizzero)Geo Media (Intergraph) da INTERLIS (per il mercato svizzero)Topobase (C-Plan) da INTERLIS o da UML

GeoUML (Politecnico di Milano, Univ. Verona)UML extension designed for spatial objects; formal, lexical representation additional to the usual UML graphic representation

26


L’open Geospatial Consortium (OGC) promuove lo sviluppo di questatecnica. Grazie alla partecipazione delle aziende leader a livellointernazionale (ESRI, Intergraph, Siemens, Microsoft, ecc.) edall’incorporazione di università e istituti di ricerca l’OCG ha ottenuto una

Interoperabilità

all incorporazione di università e istituti di ricerca, l OCG ha ottenuto unavasta risonanza e ha creato grandi aspettative.

GIS 1

GIS 2

GIS 3

GIS 4

Antworten

Anfragen

4. Interoperabilità (seguito)

I vantaggi del concetto di interoperabilità:• La gestione dei dati può essere diversa nei sistemi in comunicazione.• Il sistema che invia una richiesta non deve conoscere l’organizzazione

interna dei dati e gli algoritmi necessari nel sistema che li fornisce.• i sistemi non trasmettono che parti del proprio contenuto e i dati originali

restano sotto il proprio controllo (diritti d’autore, proprietà intellettuale)• vantaggio per i produttori di software GIS : i clienti non possono cambiare

facilmente il fornitore

I limiti:• il numero delle possibili richieste standardizzate e delle forme di risposta non

ò t dpuò essere troppo grande.

27


Limiti e prospettive

Limiti e prospettive per i metodi di trasferimento dei dati geografici e dell’interoperabilità

Sarà possibile realizzare il sogno di trasferiredati geografici tra sistemi completamente diversi o inviare loro richieste ottenendo risposta in modo totalmente automatico, ?

Si affermerà l’interoperabilità o piuttosto i metodi che trasferiscono effettivamente i dati ?trasferiscono effettivamente i dati ?

Limiti e prospettive

Limiti e prospettive per i metodi di trasferimento dei dati geografici e dell’interoperabilità

Risposta alla seconda domanda :Si affermerà l’interoperabilità o piuttosto i metodi che trasferiscono effettivamente i dati ?

Le due soluzioni sono necessarie Non sono alternative sono soluzioni complementari

28


Limiti e prospettive (seguito)

Risposta alla prima domanda :E’ possibile trasferire dati geografici di ogni tipo o inviare richieste qualsiasi,

in modo totalmente automatico ? La riposta è no !

Esiste un ostacolo teorico insuperabile: La non univocità della semanticapElementi uguali (entità, oggetti, attributi) possono essere denominati in

modo diverso (per es. case o edifici, abbreviazioni, lingue straniere, diverse istruzioni al rilevamento ecc.)

Denominazioni identiche possono avere significato diverso.

In strutture dati di diversa origine una ricostruzione automatica della semantica è impossibilesemantica è impossibile

Per sistemi federati sarà forse possibile descrivere in modo sufficientemente preciso la semantica degli elementi (ontologia)

Tema di ricerca molto attuale.

La semantica della descrizione dei dati non può essere standardizzata in un settore di attività lasciato alla libera iniziativa. Per mettere in relazione entità e attributi occorrono informazioni supplementari



TubazioniAcquedotto

annodia-metro

dia-metroTipo

Anno costr.

acqua

26

dia-metro

Anno costr.

acquagas


29


Limiti e prospettive (seguito)Le relazioni tra i sistemi devono essere decise inizialmente in base:

ad un’analisi interpretativa di un esperto, a richieste presso i responsabili e a consultazione di metadati.

In seguito è possibile eseguire la trasformazione semantica

Attenzione :Le relazioni dipendono dal significato delle classi di entità e degli attributi. Sono quindi anche influenzate dalle direttive interne dell’organizzazione e dalle regole seguite al momento dell’acquisizione dei dati.


Tra sistemi federati (organizzati con regole comuni) sarà possibile, in settori specifici, sviluppare le ontologie che descrivono la semantica di più sistemi permettendo lo sviluppo di moduli di trasformazione automatici (agenti)

ontologia

Age

nti

Age

nti

30


GIS 2

GIS 4

Il progresso continua!

Il prossimo passo: l‘interoperabilità semantica

GIS 1

GIS 3

Antworten

Anfragen

CHD

BKG

CHD

309/Feb./2005, Zürich

31


TLM

(Vektor)

CH

Web-Client

Sistema consultato

Sistema richiedente

WFS

Configurazione del WFS attuale:

Il richiedente deve conoscere lo schema del Database consultato

WFS

ATKIS Basis-DLM

(Vektor)

BW

DLM

(Vektor)

ADesktop-

GISWFS

WFS

WFS

ATKIS Basis-DLM

(Vektor)

BY

BW

High-End-GISW

FS

Collegamento InternetSv = ServerCl = Client

WFS

TLM

(Vektor)

CH

Web-Client

mdW

FS S

v

mdW

FS C

l

Sistema consultato

Sistema richiedente

Configurazione del nuovo mdWFS, quando il richiedente è in grado di definire la

trasformazione semantica

ATKIS Basis-DLM

(Vektor)

BW

DLM

(Vektor)

ADesktop-

GIS

mdW

FS S

vm

dWFS

Sv m

dWFS

Cl

ATKIS Basis-DLM

(Vektor)

BY

BW

High-End-GIS

mm

dWFS

Sv

mdW

FS C

l

Sv = ServerCl = Client Collegamento Internet

32


TLM

(Vektor)

CH

Web-Client

mdW

FS S

v

WFS

Configurazione del nuovo mdWFS, quando il richiedente usa uno schema predefinito

per la richiesta

Sistema consultato

Sistema richiedente

ATKIS Basis-DLM

(Vektor)

BW

DLM

(Vektor)

ADesktop-

GIS

mdW

FS S

vm

dWFS

Sv

Cascading WFS

(neues Modell)mdW

FS C

l

WFS

ATKIS Basis-DLM

(Vektor)

BY

BW

High-End-GIS

mm

dWFS

Sv

WFS

Sv = ServerCl = Client Collegamento Internet

Esempio di trasformazione

MAPPING MODEL TLM2AAA_Mapping =IMPORTS modTLM, testAAA, blackBoxFunctions;

...TRANSFORMATION GROUP GemeindeAbbildung EXTENDS GebietsSchluesselAbbildung =

SOURCE {modTLM.Grenzen.Hoheitsgebiet, modTLM.Grenzen.Kantonsname,modTLM.Grenzen.GebietsGeometrie,modTLM.Grenzen.hoheitsgebiet_gebietsgeometrie

WHERE modTLM.Grenzen.Hoheitsgebiet.ObjectVal = #Gemeindegebiet}TARGET {AX_KommunalesGebiet,

testAAA.AdministrativeGebietseinheiten.TS_SurfaceComponent,testAAA.AdministrativeGebietseinheiten.multisurface_surfacecomponent}

MAPPING { ALL {AX_KommunalesGebiet.gemeindekennzeichen.land := 'Schweiz';AX_KommunalesGebiet.gemeindekennzeichen.kreis := Kantonsname.Name;AX_KommunalesGebiet.gemeindekennzeichen.gemeinde := Hoheitsgebiet.Name;AX_KommunalesGebiet.gemeindeflaeche := Hoheitsgebiet.GemFlaeche;TS SurfaceComponent part := GebietsGeometrie part;TS_SurfaceComponent.part : GebietsGeometrie.part;multisurface_surfacecomponent.multisurfacecomponent :=

hoheitsgebiet_gebietsgeometrie.hoheitsgebiet;multisurface_surfacecomponent.position :=

hoheitsgebiet_gebietsgeometrie.position;

} }END GemeindeAbbildung;

END TLM2AAA_Mapping.

33


Spatial data infrastructures and interoperability

Peter Staub

ETH Zürich, Institut für Geodäsie und Photogrammetrie

Gruppe GIS und Fehlertheorie

35

P. Staub, ETHZ – Spatial data infrastructures and interoperability

Spatial Data Infrastructures and Interoperability

Content

1 – What is a spatial data infrastructure (SDI)?1 What is a spatial data infrastructure (SDI)?

2 – NGDI Switzerland / e-geo.ch

3 – European SDI: INSPIRE

4 – Interoperability

5 – Model-based data transfer

37


What is a Spatial Data Infrastructure (GDI)?

• Connected/networked databases• Functionality to handle the concerned dataFunctionality to handle the concerned data

• Institutional, organisational technological, and economical resources to support the development and the maintenance of the SDI

• User + network + rules + standards + data

Network

R lU DRules

Standards

User Data

Quelle: Bernard et.al.

• Integration of most different datasets/datapools• Interoperable use of the available data

EU: INSPIRE directiveNGDI Switzerland Interoperability Model transformationWhat is a SDI?

Example Switzerland: NGDI

Objectives of the Swiss NGDI: dispel/clear existing problems concerning geodata handling and assure enduring a broad use of g g g ghigh quality geoinformation.

Geobasisdaten metainformations basic geoservices

technical (advanced) Network

Swiss national geodata-infrastructure NGDI

* Bundesgesetz über Geoinformation (Geoinformationsgesetz, GeoIG) vom 5. Oktober 2007


technical infrastructure

guidelines and standards legal fundamentals* pricing strategy

(advanced) training/research

Networke-geo.ch

38


INSPIRE Directive

• The INSPIRE directive defines the general framework and the objectives for the implementation of the European geodata j p p ginfrastructure (GDI).

• The objectives of INSPIRE are defined in detail through implementation rules and regulate the transfer of geodata of the member countries to the European commission.

• Techn./organ. requirements for the establishment of GDI and definition of interface standardsdefinition of interface standards.

• Main objective of INSPIRE: common use of geodata and geoservices in the field of environmental applications.

Interoperability techniques have to be applied and data have to be exchanged via network services.


INSPIRE Directive: Principles

Besides superior objectives, concrete demands were defined as milestones and points-of-reference.p

subsidiarity

interoperability scalability

Quelle: Bernard et.al.

data policy

transparence comprehensibility


39


Definitions (1)

• Interoperability (following INSPIRE)– The ability of systems to collaborate y y– Mutual usage of services and exchange of data via interfaces– Inclusion of pertinent/relevant standards

• Syntactic interoperability– The structures of the interfaces or data formats (syntax), respectively,

are well-known and useable among involved systems– General precondition for interoperability

• Semantic interoperability– All of the above, and furthermore:– The meaning of structures (i.e. semantics) are well-known and useable

among involved systems.


Definitions (2)

• Conceptual model: bearer of semantic information

• Model based data transfer–Transfer of conceptual model together with data–Possibility to exchange and publish data with their semantics

• Model transformation–Mapping of different conceptual models– Is needed to establish semantic interoperability when:Mapping/transformation rules

Source model Target modelIs needed to establish semantic interoperability when:

o Modelsource system ≠ Modeltarget system

o Modeltarget system remains static

pp gBuilding House

IDZIPStreetStrNoArea

IDAdressGeometry


40


Prerequisites for interoperability

Stefan Henrich



41

S. Henrich, ETHZ – Prerequisites for interoperability

Prerequisites for Interoperability

Concepts and Solutions

Présuppositions pour l‘interopérabilité

Concépts et Solutions

Content

1 – Data exchange among GIS in general1 Data exchange among GIS in general

2 – Exchange Process and its Problems

3 – Format based and model-driven Transfer

4 – Example in 5 steps

5 – Model Transformation

43


Data exchange among GIS (1)

remainingland cover waterbodies

GIS A

3

forest grassland agriculture waterbodiesGIS B


remainingdata waterbodies

GIS A

Land Cover

forest grassland agriculture waterbodiesGIS B

44


• every GIS has an export function to create ASCII (nowadays XML) data• every GIS can import the data that was exported beforehand


Faaaaaaaa!bbbbbb!ccccccc!ddd!P11!22!333333333!444444444!5555555!666!777!P11!22!333333333!444444444!5555555!666!777!P11!22!333333333!444444444!5555555!666!777!P11!22!333333333!444444444!5555555!666!777!Faaaaaaaa!bbbbbb!ccccccc!ddd!P11!22!333333333!444444444!5555555!666!777!P11!22!333333333!444444444!5555555!666!777!

Fx2237781!0600.4!0001090!003!P14!33!600344.24!203112.44!0780.22!234!100!P25!87!620432.88!206334.67!0654.36!554!100!P87!66!614788.38!208443.88!0698.66!655!100!P76!19!611733.73!202735.54!0704.01!359!100!Fx2237782!5233.4!0023023!003!P57!18!690001.38!133877.85!0450.22!344!113!P37!98!694043 00!145733 03!0470 43!857!113!

Fx2237781!0600.4!0001090!003!P14!33!600344.24!203112.44!0780.22!234!100!P25!87!620432.88!206334.67!0654.36!554!100!P87!66!614788.38!208443.88!0698.66!655!100!P76!19!611733.73!202735.54!0704.01!359!100!Fx2237782!5233.4!0023023!003!P57!18!690001.38!133877.85!0450.22!344!113!P37!98!694043 00!145733 03!0470 43!857!113!

area identpoint data" "" "" "

area identpoint data" "

Data fields, as exported by GIS A

P11!22!333333333!444444444!5555555!666!777!...P37!98!694043.00!145733.03!0470.43!857!113!...P37!98!694043.00!145733.03!0470.43!857!113!...

(definition of area feature; points with coordinates)


D01 1111 2222 33 44 555555555 666666666 7777777D01 1111 2222 33 44 555555555 666666666 7777777

Data fields, as exported by GIS Z

D01 1111 2222 33 44 555555555 666666666 7777777D01 1111 2222 33 44 555555555 666666666 7777777...

1 aaaaaaaa bbbbbb cccccc dddd eeee dddd eeee dddd eeee2 dddd eeee dddd eeee dddd eeee dddd eeee dddd eeee dddd eeee2 dddd eeee dddd eeee

(point id and coordinates)

1 aaaaaaaa bbbbbb cccccc dddd eeee dddd eeee dddd eeee1 aaaaaaaa bbbbbb cccccc dddd eeee dddd eeee dddd eeee2 dddd eeee dddd eeee dddd eeee dddd eeee dddd eeee...

(definition of area feature, without coordinates)

45


Exchange process and its Problems (1)

• 1:1 Processor– Analyse transfer formats of the two involed GIS systems (reverse

1:1

y y (engineering, maybe documentation)

– Implement 1:1 processor to transform data from transfer format A(TF-A) to transfer format Z (TF-Z) using tools like awk, grep, perl or a programming language

1:1

FM-AFM-AFM-A FM-ZFM-Z TF-Z GIS ZGIS A TF-A FM-Z

Exchange process and its Problems (1)

• Problems when using this kind of data exchange– What is the meaning of a data field? Fx2237781!0600.4!

OBJ-ID?Transfer-ID?

Restrictions? Constraints? Domains?– Need of two 1:1 processors for each GIS combination

Software Development?Software Maintenance? (change of export/import format!)

1:11:11:11:11:1

altitude?feature length?

GIS A

1:1

GIS ZGIS X

1:11:1

GIS U

1:1

GIS V

1:1

GIS W

46


Format based transfer

• Partial solution: – Standardise the transfer format

GIS Z

GIS U

GIS V

GIS W

GIS AGIS X

GIS U

Model-driven approach (MDA) (1)

• But: Content of the data fields still not described yet – Describing the data in prose may lead to misunderstandings between g p y g

sender and receiverUse of formal language minimises mistakesFormal language can be read by computers

Let's not describe the data fields of the transfer file BUT the structure of the transfered data (i.e. tables/classes with their corresponding attributes)

Out of this description of the data structure (the data model, aka conceptual schema) the computer shall produce the schema of the transfer file

47


Model-driven approach (MDA) (2)

• Benefits of a model-driven transfer – Simplification and clarification of the data structure and the transfer p

format– Different models may be transfered using the same formal language

• Content of a model-driven transfer standard– a Conceptual Schema Language (CSL)– a mechanism that derives the description of the transfer format from the

conceptual schema

Do data modelling first, then do transfer.

Example: From Reality to the Transfer file

• Using the following five steps 1. Description of the data in prosep p2. Graphical modelling using UML3. Description of the UML model in a formal (computer-readable) language4. Automatic description of the transfer file format5. Example of a transfer file

48


Example Step 1

• Description of the data in prose – Topic: Swiss Cadastral Register, land coverp g ,– Description already given in Swiss law

…

49


…

Example Step 2

• UML Diagram: Package "Land Cover"

LCMaintenance

MLIdentIdDescriptionPerimeterValidityDate1Date2

SingleSpot

Id+Origin 1

+singleSpot 0..*

+Origin

0..1

+Origin

1

LaArea

GeometryQualityKind

GeometryPositionAccPositionRelExactlyDefined

+laArea0..*

+Object

1

+Object

1

50


Example Step 3

• Description of the UML Model using the CSL INTERLIS

TOPIC LandCover =TOPIC LandCover =

DOMAIN

LCKind = (building,fixed(street_path,sidewalk,traffic_island,course,

airfield,water_basin,remaining_fixed),waterbodies(stationary,flowing,reed_zone));

CLASS LCMaintenance =MLIdent: MANDATORY TEXT*8; LCMaintenance

Id: MANDATORY TEXT*12;Description: MANDATORY TEXT*30;Perimeter: SURFACE WITH (STRAIGHTS, ARCS) VERTEX

Point2D WITHOUT OVERLAPS > 0.050;Validity: Status;Date1: TEXT*10;Date2: TEXT*10;

UNIQUE MLIdent, Id;END LCMaintenance;

MLIdentIdDescriptionPerimeterValidityDate1Date2

Example Step 3 (continued)

• UML description using INTERLIS (continued)

CLASS LaArea = LaAreaCLASS LaArea =Geometry: MANDATORY AREA WITH (STRAIGHTS, ARCS)

VERTEX Point2D WITHOUT OVERLAPS > 0.050;Quality: MANDATORY QualityStandard;Kind: MANDATORY LCKind;

END LaArea;

ASSOCIATION laAreaOrigin =laArea -- {0..*} LaArea;

GeometryQualityKind

LCMaintenance

+Origin 1

Origin -- {1} LCMaintenance;END laAreaOrigin;

!! Additional classes and associations

END LandCover;

LaArea

+laArea0..*

51



• Structure of an INTERLIS file

INTERLIS 2 3;INTERLIS 2.3;MODEL <ModelName> AT "http://www.gis.ethz.ch" VERSION "12" =DOMAIN!! Attribute types and domain definitions, valid for ALL topicsTOPIC <TopicName1> =

CLASS <ClassName1> =!! AttributesEND <ClassName1>;CLASS <ClassName2> =!! AttributesEND <ClassName2>;ASSOCIATION <AssociationName1> =!! Definition of roles, cardinality and multiplicityEND <AssociationName1>;!! Additional classes and associations

END <TopicName1>;TOPIC <TopicName2> =

!! Classes and associationsEND <TopicName2>;

END <ModelName>.


Example from the Swiss Government

Model of the Swiss Federal Survey

52


• Benefit of a CSL (among others): Domain of attributes– Base types


yp• Text Name: TEXT*30;• Value domain Weight: 0 .. 300 [kg];

HeightOfTower: 40.0 .. 150.0 [m];GroundArea: 10 .. 200 [m2];

• Enumeration Color: (green,red(dark_red,orange));• Coordinates 2D Point2D = COORD 480000.000 .. 840000.000 [m],

70000.000 .. 300000.000 [m];

– Domain references (e.g. LCKind)• Description of a domain in a DOMAIN section, valid for the whole data model

– Line type• Polyline


POLYLINE WITH (STRAIGHTS,ARCS) VERTEX Point2D;

– Surface type• Surface

SURFACE WITH (STRAIGHTS,ARCS) VERTEX Point2DWITHOUT OVERLAPS > 0.050;

– Area type• Area

AREA WITH (STRAIGHTS,ARCS) VERTEX Point2DWITHOUT OVERLAPS > 0.050;

53


• INTERLIS compiler creates the schema of the transfer file– Old format (INTERLIS 1, .fmt)

Example Step 4

( , )

SCNTTOPI LandCover!!!!TABL LCMaintenanceOBJE 11111111 222222222222 333333333333333333333333333333 \CONT 4.. !!!!!!!! 1: MLIdent!!!! 2: Id!!!! 3: Description!!!! 4: ......!!!!ETAB

• INTERLIS compiler creates the schema of the transfer file– New format (INTERLIS 2, .xsd (XML schema))

Example Step 4 (cont.) + 5

( , ( ))

<xsd:complexType name="Test23.LandCover.LCMaintenance"><xsd:sequence><xsd:element name="Id"><xsd:simpleType><xsd:restriction base="xsd:normalizedString"><xsd:maxLength value="12"/>

</xsd:restriction></xsd:simpleType>/ p yp

</xsd:element><xsd:element name="Description"><xsd:simpleType><xsd:restriction base="xsd:normalizedString"><xsd:maxLength value="30"/>

</xsd:restriction></xsd:simpleType>

</xsd:element>

54


• INTERLIS compiler creates the schema of the transfer file– Corresponding data

Example Step 4 (cont.) + 5

p g

<Test23.LandCover BID="ch03d6gw00000197" KIND="INITIAL" ENDSTATE="state0"><Test23.LandCover.LCMaintenance TID="ch03d6gw00000198">

<Id>1852</Id><Description>Change of border</Description><Date1>2001:09:23</Date1><MLIdent>ZH302202</MLIdent><Validity>planned</Validity>

</Test23.LandCover.LCMaintenance><Test23.LandCover.LCMaintenance TID="ch03d6gw00000199">

<Id>1854</Id><Description>New Building Supermercato</Description><Date1>2001:10:07</Date1><MLIdent>ZH302201</MLIdent><Validity>planned</Validity>

</Test23.LandCover.LCMaintenance>

Conclusion

• Benefit of the INTERLIS transfer format – The format is well-defined; it is derived from the model;– Independent checking of the data is possible (quality management)– The transfer data is in a system-independent form; it is both human and

machine readable (documentation, archive)

26

55


Model Transformation

FM-A FM-Z

ModelMapping

CSL CSL

DM-A DM-Z

SFM-A SFM-Z

27

1:1

TF-ZGIS A GIS ZTF-A STF-ZData Trans-formation

1:1

STF-A

56


Semantic interoperability for INSPIRE: the Swiss-German solution – research project “Model-Driven WFS”

Peter Staub



57

P. Staub, ETHZ – Semantic interoperability for INSPIRE: the Swiss-German approach – research project „Model-Driven WFS“

Semantic Interoperability for INSPIRE

The Swiss-German solution – research project „Model-Driven WFS“

Interopérabilité sémantique pour INSPIRE

La solution Suisse-Allemande – projet scientifique „Model-Driven WFS“

Content

1 – Case study, INSPIRE1 Case study, INSPIRE

2 – Problem and solution

3 – Formal language for semantic transformations

4 – Extension of the WFS interface

5 – Live demo

59


Case studySource systems

V t WF

ATKIS Basis-DLM

(AAA)

Vector 25

ATKIS

WFS

FS

WFSClient

INSPIRE Data Specifications

Target system

U t d t th t fit th ti

User wants data that fits the model of the target system

• OGC web services allow for syntactic interoperability• Semantic interoperability only possible if

data modelsource system = data modeltarget system

ATKIS Basis-DLM

(AAA)

WFS

User gets data that fits the respective model of the source system

Case study, INSPIRE Problem/solution Formal language WFS Extension Live demo

Case study

60


Problem

Germany:AFIS-ATKIS-ALKISEU: INSPIRE

Data Specifications

Suisse:GG25, Vector25


• Data model EuroSpec FC(Administrative Boundaries)

Problem

( )


61


Problem

• Data model AAA (Administrative Gebietseinheiten und Kataloge)


Problem

• Data model GG25 (Gemeidegrenzen)


62


SolutionSource systems

V t WF

md

ATKIS Basis-DLM

(AAA)

Vector 25

ATKIS

WFSClient

INSPIRE Data Specifications

Target systemWFS

FS

m

mdWFS

WFS

U t d t th t fit th ti

User wants data that fits the model of the target system

• OGC web services allow for syntactic interoperability• Semantic interoperability with semantic transformation; defined

by rules on the conceptual level

ATKIS Basis-DLM

(AAA)

WFS

dWFS


User gets data that fits the respective model of the target system

Solution

Concept of the model-driven WFS

• Requirement

- Access to object-structured geodata based on- existing source-datamodel of the geodata- user-definied target datamodel

- Interoperability with existing OGC Web Services

P i f b b d d l t f ti• Premises for web-based model transformations

- Description of datamodels using CSL

- Formal language to describe model mappings/transformations

- (extended) Web Service interface


63


Prototype implementation

mdWFS-ST OGC WFS OGC WFS

Presentation level/User

Client Client Client

Application level

mdWFS-ST (deegree Framework)

Transformation Module

WFS

mdWFS-STInterface

OGC WFSInterface1

6

0

ORACLE 10g Data storage level

Module ili2ora 2

3

4

5


64


Model-mapping language

Requirements

• Comprehendible for non-computer scientists

• Definition of a meta-model and syntax for HUTN

• Visual, textual, and XML representation of transformation models

• International standards taken into account• International standards taken into account

• (Geo-) datatypes


65


Fundamentals

Language concept

• Independent extension of the UML-MetamodelThe metaclasses of the language inherit all properties of UML

- Modelling of complex transformation processes- Potential: conditional execution, switches, loops

• Based on UML activitiy diagrams

d l f h l d l• Metamodel of the language is a UML 2 model

• Textual notation: EBNF syntax rules

• Name: UMLT


Language concept – UMLT metamodel

ExecutableNode

Activity StructuredActivityNode Action

OpaqueAction<<metaclass>>StructuredTransformation

<<metaclass>>TransformationAction

<<metaclass>>TransformationActivity

<<metaclass>>MappingRule

<<metaclass>>SelectionCriteria

ownedLogicalExpression : Expression

<<metaclass>>AssociationBinding

leftRole : PropertyrightRole : Property


<<metaclass>>AssignmentDefinition

<<eAttribute>> ownedTargetElement : ValueSpecification<<eAttribute>> ownedExpression : ValueSpecification

jointType : JoinType

<<enumeration>>JoinType

equijoinleftjoin

rightjoin

<<metaclass>>VirtualAssociation

{ isDerived = true }

joinCriteria : Expression

66


UMLT Example Source and target datamodels


UMLT ExampleTransformation model


67


MAPPING MODEL E l T f M d l ( ) AT " i th h" VERSION "0 1"

UMLT ExampleTransformation model in textual notation

MAPPING MODEL ExampleTrafoModel (en) AT "www.gis.ethz.ch" VERSION "0.1" =

IMPORTS SourceModel; IMPORTS TargetModel; IMPORTS UNQUALIFIED SpatialOperations;

TOPIC ExampleTopic =

ACTIVITY ExampleTrafoActivity =

TRANSFORMATION ExampleTrafo =IN linesIN: SourceModel.SourceTopic.A;IN pointsIN: SourceModel.SourceTopic.B;OUT areaOUT: TargetModel.TargetTopic.C;OUT areaOUT: TargetModel.TargetTopic.C;

TRAFO_ACTION Lines2Polygon =IN linesIN_1{*..*};OUT polygonOUT;MAPPINGpolygonOUT := Topo.polygonbuilder(linesIN_1, linesIN_1->geom);

END Lines2Polygon;


./.

TRAFO_ACTION TransferCetroidInfo2Area =IN polygonIN;IN centroidPointsIN;OUT areaOUT_1: TargetModel.TargetTopic.C;VARIABLE temp;MAPPINGtemp := Topo.areabuilder(polygonIN, polygonIN->geom,

centroidPointsIN, centroidPointsIN->geom);areaOUT_1->geometry := temp->geom;areaOUT_1->kind := temp->art;

END TransferCetroidInfo2Area;

CONTROLFLOWSTART_FLOW ---Lines2Polygon;Lines2Polygon --- TransferCetroidInfo2Area;TransferCetroidInfo2Area --- END_FLOW;

DATAFLOWDATAFLOWlinesIN ---Lines2Polygon.linesIN_1;Lines2Polygon.polygonOUT --- TransferCetroidInfo2Area.polygonIN;pointsIN --- TransferCetroidInfo2Area.centroidPointsIN;TransferCetroidInfo2Area.areaOUT_1 --- areaOUT;

END ExampleTrafo;END ExampleTrafoActivity;END ExampleTopic;END ExampleTrafoModel.


68


UMLT ExampleXMI


WFS: state of the art (i.e. OGC WFS 1.1.0)

• WFS = – OGC standard version 1.1, ISO standard 19142 in preparationOGC standard version 1.1, ISO standard 19142 in preparation– Web Service interface to:

• Access object-structured vector data• Select geo-objects (Features) based on their

attribute values (Filter Encoding)

• Transfer format for data: GML• Transfer format for format schema: XMLSCHEMA• Distinction between Basic WFS (reading access) and transactional Distinction between Basic WFS (reading access) and transactional

WFS (read+write)• Basic WFS operations:

– GetCapabilities– DescribeFeatureType– GetFeature


69


WFS: Extensions

• Adjustment of GetCapabilities operation:– Information regarding new operation DoTransformInformation regarding new operation DoTransform– <schemaList> analogous to ordinary <featureTypeList>

• Adjustment of DescribeFeatureType operation:– Description of conceptual model [XMI]

in addition to description of transfer format [XMLSCHEMA]

• Whole new Operation DoTransform:– Executes semantic transformationsExecutes semantic transformations– Configures a new, OGC-compliant WFS instance– Parameters:

• ID of source model• Description of target model [XMI]• Transformation rules [UMLT/XMI]


Prototype implementation

Client = Target System

Model B: UML/XMI

Server = Source System

Model A: UML/XMI

0

mdWFS1

Request model catalogue

2Provide model catalogue

3Order required model

4Send ordered model A [XMI]

5 Establish Model Mapping A Bili2ora

D T f Request

7 ili2ora

ORACLE

WFS

SQL/Java

8A B

6DoTransform-Request

Model B + Trafo. Model A B [XMI]

deegree

9Model B

DoTransform-Response10

GetCapabilitiesDescribeFeatureType

GetFeature11


70


mdWFS: Demo

„INSPIRE case“


71



1) deegree WFS web interface


2) WFS feature-types (I), pre-transformation

72



3) Generic OGC web service client


4) WFS GetCapabilities

73



5) mdWFS GetCapabilities


6) mdWFS DoTransform

74



7) WFS feature-types (II), post-transformation


8) WFS GetFeature

75


References

Donaubauer A., Fichtinger A., Schilcher M., Straub F., Carosio A., Gnägi H.R., Morf A., Staub P. (2006): Grenzübergreifende GIS-Lösungen. GIS Zeitschrift für Geoinformatik 9/2006:29-34.

Donaubauer A., Staub P., Straub F., Fichtinger A. (2008): Web-basierte Modelltransformation –eine Lösung für INSPIRE? GIS Zeitschrift für Geoinformatik 2/2008:26-33.

Staub P. (2007): A Model-Driven Web Feature Service for Enhanced Semantic Interoperability. OSGeo Journal 1(3):38-43.

Staub P., Gnägi H.R., Morf A. (2008): Semantic Interoperability through the Definition of Conceptual Model Transformations. Transactions in GIS 12(2):193-207.

Donaubauer A., Fichtinger A., Schilcher M., Straub F., Carosio A., Gnägi H.R., Morf A., Staub P. (2006): Modellbasierter Ansatz für den Web-Zugriff auf verteilte Geodaten am Beispiel ( 006) ode bas e te sat ü de eb ug au e te te Geodate a e sp egrenzübergreifender GIS-Anwendungen. Interner Forschungsbericht zur Projektphase I, 2006.

Donaubauer A., Schilcher M., Straub F., Carosio A., Morf A., Staub P (2007): Modellbasierter Ansatz für den Web-Zugriff auf verteilte Geodaten am Beispiel grenzübergreifender GIS-Anwendungen. Interner Forschungsbericht zur Projektphase II, 2007.

76

Session II – Other aspects of interoperability

Ontologies evolution: from social sciences‘ needs to interop opportunities

Eduardo Camacho-Huebner

EPF Lausanne, School of Architecture, Civil and Environmental Engineering

Laboratoire de systèmes d’information géographique

77

Ontologies evolutionfrom social sciences needs to interop opportunities

Comitato scientifico italo-svizzero per la geoinformazioneLes Marécottes - June 16th 2008

[email protected]

Summary

Introduction: research context

Information structuration

Reducing historical knowledge to geo-historical data (limits)

Stability conditions: polysemy and historical evolution of concepts

Conclusions and perspectives

E. Camacha-Huebner, EPFL - Ontologies evolution: from social sciences' needs to interop opportunities

79

Research context

Urban morphology: ideas and facts!

History of concepts, cultural history...

Social history, urban history...

Architecture, urban design, typo-morphology...

Historical geography, archaeology, urban studies...

Geographic information science, quantitative geography, spatial analysis...


80


Geo-historical database

Elementary information: entities, properties and relationships

Explicit kernel (links between concepts and classes)


81

1726 - 1728

1896 - 1911

2006


Ontology

Morphological and historical concepts

Semantic relationships


82


83

Historical knowledge

Limits to the reduction of historical knowledge:

Heterogeneous sources (primary, secondary and tertiary sources; cartographic, textual and iconographic

sources...)

Partial data sets (indiciary paradigm, traces, suspicion...)

Rigidity of data structures (databases, instances vs. classes / attributes)

Sources incomparability (non-significative data)

Historical and semantic relativity of concepts (polysemy, evolution of concepts...)

Non-reproducible information (by experiments or simulation)

Stability conditions

Conceptual stability conditions

measure

comparison

interpretation

implementation

Two main problems:

semantic translation (polysemy and multilingual corpuses)

historical evolution


84

Polysemy

Stability of definitions

Synonymy and homonymy

disambiguation (concepts)

points of view (conceptualization and arrangements)

declarative sematics (Tarski)

ontologies alignement


85


86

Historical evolution

Historical stability: intervals of validity

Evolution of signification

historical context reduction: epoch-based ontologies

categorization of meta-processes


87

Conclusions and perspectives

From theoretical issues to interoperability opportunities:

Meta-modeling inspired from social sciences paradigms

Semantic and historical relativity epitomizes the nature of interop problems at the conceptual level

Defining validity intervals

Dealing with multiple points of view


88


Institute of Earth Science: current and future activities at the geomatics division

Dr. Massimiliano Cannata

SUPSI Lugano, Istituto Scienze della Terra

89

M. Cannata, SUPSI – Institute of Earth Science: current and future activities at the geomatics division

Institute of Earth Science:

current and future activitiescurrent and future activitiesat the geomatic division

Research objective

Geoinformation Technology for Natural Disaster Management and g

Sustainable Development

Developing a Risk Management System

91


Motivations

Some of the lessons learned in theSome of the lessons learned in the last several years give clear indications that availability,

management and presentation of geo-information play a critical role ingeo information play a critical role in

disaster management and sustainable development.

The effect ofglobalwarming on

Disaster

weatherpatterns maybe responsiblefor anapparentincrease in thefrequency andintensity of

Natural disasters are impacting upon mankind with relentless frequency and intensity and have taken a heavy toll in recent years.

intensity ofweather-relateddisasters.

92


Risk assessment analysis allows the development of natural hazard mitigation planning.

Mitigation

g p g

Hazard Mitigation planning is the process of developing a set of actions designed to reduce or eliminate long-term risk to people and property from hazards and their effectstheir effects.

Those plans if actuated allow to reduce: economic losses, killing and injuring, historical and architectural

heritage damages.

Geomatic is fundamental in Risk analysis (solving the “localization” issue) as shown by the Swiss Re®

insurance company applications:

Risk and Geoinformation

insurance company applications:

93


Geoinformation domains of a risk management system

Data: updated information collection, storing and servingAnalysis: hazards modelling and risk

tassessmentOperational: information access & decisions

Key components for Data domain

OBJECTIVEI t bilit f d t i t ti d iInteroperability for data integration and serving

METHODapplication of OGC Standard Services

(WMS, WCS, WFS, WPS, SOS) MOTIVATIONSMOTIVATIONS

They are widely used and many tools implement them.

94


Key components for Analysis domain

OBJECTIVEM d l i t ti d iModels integration and serving

METHODdevelopment of GIS modules in GRASS and

serving trough WPSMOTIVATIONSMOTIVATIONS

GRASS has numerous modelling modules.A WPS implementation using GRASS exists

(PyWPS)

Key components for Operational domain

OBJECTIVEdi t ib t i f ti t ti l idistribute information to operational agencies

METHODdevelopment user friendly Web interfaces for data

visualization and analysis(OpenLayers MapBuilder PyWPS 52N-SOS)(OpenLayers, MapBuilder, PyWPS, 52N SOS)

MOTIVATIONSWeb is worldwide available and offer the

necessary “real time” communication

95


Risk Management System

Application server

Geo-database server

DATA DOMAIN

ANALYSIS DOMAIN

Service server

serverserver

OPERATIONAL DOMAINClient

Front-end server

IST running projects

St. Lucia Drought hazard mappingRomania Landslide Hazard monitoring andalarm system: a pilot applicationEmergency planning for Population Protectionagency of the Canton TicinoDevelopment of risk standards for the touristpsector in the Caribbean areaSNSF-FP52 risk assessment for theinfrastructure sector

96


IST “future” projects

IPCC second national communicationdevelopment for St. LuciaClimate change V&A assessment: developmentof geoinformation system

Research status on Analysis domain

GIS-GRASS embedded natural hazard models

97


r.rockconeRockcone implementa un metodo speditivoed a bassa richiesta di dati, per la stima dellearee potenzialmente interessate da cadutasassi. Si basa su un modello empirico: unmasso da un punto di distacco si propagalungo la pendenza e si arresta generalmentead una distanza massima individuatadall'intersezione della topografia con una“superficie di energia” con origine nel punto didistacco e pendenza φ con l'orizzontale.

0 < ΔX2 + ΔY2 – (tg(Π/2-φ))2 * (Zo – Z)2

v = fv * sqrt(2g Δh) Ep = m g Δh ; Ek = ½ M v2

fv = fattore di velocità rotazionale (es.: 0.9)

r.rockcone

Energia potenziale (J)

98


r.dfwÈ un modello empirico-concettuale peril calcolo delle superfici interessate daun flusso di detrito che fa uso di unapproccio statistico (simulazioneapproccio statistico (simulazioneMonteCarlo) basato sulla definizionedi soglie per la determinazionedell’area soggetta a deposizione suconoide e di un semplice modello dideflusso (Perla).

r.dfw

Velocità media (m/s)

99


r.tsunami

A shallow slope off the coast shown in the Figure below will allow a greater surge toFigure below will allow a greater surge to inundate coastal communities. As the water depth decreases closer to the shore, the excess water is not able to dissipate.

r.tsunami

Hydraluc model for Inundation ti ti

I = r * Rh - e

I = inondazione

r = indice di scabrezza

estimation

Rh = water levels (includes the astronomical tide, storm surge, and wave runup)

e = elevazione del terreno

100


r.tsunami

Inundation height map [m] for different return periods

T=500 T=750

Research status on Analysis domain

GIS-GRASS embeddedrisk assessment procedures

101


Classification of the inundation map according to the hazard matrix: Intensity Vs Frequency

Hazard assessment

matrix: Intensity Vs Frequency

High

medium

INTE

NSI

TY

* *

High medium low

low

PROBABILITY

IN

*

High

medium

low

null

Exposition assessment

Overlay of hazard map and element at risk

102


Value of the exposed elements [€/m2]

- Function of the construction and landuse type

Industrial

Rural

House value

800 € / m2

500 € / m2

House type

Rural

Urban 1700 € / m2

800 € / m

Value of the buildingcontents

- A multiplicative factor of the house value

Ref.: US Army Corps of Engineers Hydrologic Engineering Center, 1988; P. De Lotto, G. Testa, 2002

103


Direct damages due to inundation assessment

D = V * Gv

Vulnerbility degree

It is estimated from vulnerability curves derived from statistical data analysis

Value

y(Ref.: US Army Corp of

Engineering - Hydraulic

Center)

Example of vulnerability curve for residence buildings

Curve di vulnerabilità classe di danno A

0.8

0.3

0.4

0.5

0.6

0.7

danno% Struttura A

Contenuto A

0.0

0.1

0.2

0.0 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0 11.0

altezza acqua (m)

104


Expected direct damages for low probability events

(€ / 750 )years)

Expected direct damages for low probability events

(€ / year)

105


Research status on Operational domain

OGC services and

application implementationimplementation

Research status on Operational domain

Population Protection emergency action planning

A web interface for planning and sharing intervention action among emergency actors

(Police, civil protection, fire brigade, pandemic agency, etc...)

Implementation of WMS and WFS services and development of user friendly interfaceA first draft: http://localhost/ProtPop/

106


Research status on Data domain

SOS services and

application explorationexploration

SGM 2008 – Lugano 21-23 Nov.Symposia: Data acquisition, Geo-processing, GIS, digital

mapping and 3D visualisation

107


Swiss local chapter: OSGeo.ch

Chapter Roles

Open Source software has come to be a proven environment for building stronger software through open globalOpen Source software has come to be a proven environment for building stronger software through open global collaboration. The Open Source Geospatial Foundation, hereafter referred to as OSGeo, has been created to support and build the highest-quality geospatial software.

The OSGeo's goal is to promote the use OSGeo projects globally by fostering strong localized OSGeo partnership and presence in different geographic and linguistic domains. Apart from being a strong local voice for the OSGeo, some of the major tasks whereby localized OSGeo partnership and presence could enrich and enhance global geospatial initiatives would be;

Provide member networking opportunities for support and job opportunities

Software Internationalization and LocalizationSoftware Internationalization and Localization

Development of prototype applications to demonstrate Open Source geospatial capabilities to local and regional audiences

Software Packaging and Customization for local and regional needs

Training, Support and Development of e-Learning Contents in local languages

Support Open standards and Open access to geospatial data in region

Risk Management System

108


Sensor observation service (SOS): insights and implementations

Milan Antonovic

SUPSI Lugano, Istituto Scienze della Terra

109

M. Antonovic, SUPSI – Sensor observation service (SOS): insights and implementations

SOSSensor Observation Service

SOSSensor Observation Service

The Sensor Observation Service aggregates readings from live, in-situ and remote sensors. The service provides an interface to make sensors and sensor data archives accessible viasensors and sensor data archives accessible via an interoperable web based interface.

111


SWESensorWeb Enablement

The SWE Working Group, is establishing the interfaces and protocols that will enable a “Sensor Web” through which applications and services will be able to access sensors of all types over the Web.

The SOS (Sensor Observation Service) is part of the OGC's SensorWeb Enablement (SWE) group of specifications.

1. Observations & Measurements (O&M) 2. Sensor Model Language (SensorML) 3. Transducer Markup Language (TML) 4. Sensor Observation Service (SOS) 5. Sensor Planning Service (SPS) 6. Sensor Alert Service (SAS) 7. Web Notification Service (WNS)

O&M Observations & Measurements

•Standard models and XML Schema for encoding observations and measurements from a sensor, both archived and real-time.

112


SensorMLSensor Model Language

•Standard models and XML Schema for describing sensors systems and processes associated with sensor observations

•Provides information needed for discovery of sensors, location of sensor observations, processing of low-level sensor observations, and listing of taskable properties, as well as supports on-demand processing of sensor

TMLTransducer Markup Language

•The conceptual model and XML Schema for describing transducers and supporting real-time streaming of data to and from sensor systems.

113


SPSSensor Planning Service

•Standard web service interface for requesting user-driven acquisitions and observations. This is the intermediary between a client and a sensor collection management environment.

SASSensor Alert Service

•Standard web service interface for publishing and subscribing to alerts from sensors.

114


WNSWeb Notification Services

•Standard web service interface for asynchronous delivery of messages or alerts from SAS and SPS web services and other elements of service workflows.

SOSSensor Observations Service

•Standard web service interface for requesting, filtering, and retrieving observations and sensor system information. This is the intermediary between a client and an observation repository or near real-time sensor channel.

•Four profiles are defined within the SOS specification: core, transactional, enhanced, and entire.

115


Application of SOS•Sensors and sensor networks gain value from theSensors and sensor networks gain value from the use of their observations

•How to get data and information out of the sensor network and integrated with other sensor data, models, and decision support systems?

•Need a framework that is flexible and that can be expanded (new sensors, models, tools need to be accommodated)

Application of SOS

Sensors -> Sensor constellation -> Sensor Webs -> Decision Making

116


SOS Overview• Provide standardized query access to sensor data that is

applicable to multiple types of sensors

• Provide query results in standardized format (Observations & Measurements)

• Observations defined byeventTime when was the measurement made- eventTime – when was the measurement made

- featureOfInterest – what entity is being measured- observedProperty - what characteristic was measured - procedure - how was it measured

SOS Overview

“An Observation is an Event whose result is an estimate of the value of some Property of theFeature-of-interest, obtained using a specified

Procedure”

117


SOS Mandatory OperationsGetObservation:access to sensor observations and measurement data via aaccess to sensor observations and measurement data via a spatio-temporal query that can be filtered by phenomena.

GetCapabilities:SOS service metadata for requesting a self-description of the service.

DescribeSensor:information about the sensors, their processes and platforms in SensorML.

SOS Optional Operations•GetResultGetResult•GetFeatureOfInterest•GetFeatureOfInterestTime•DescribeFeatureofInterest•DescribeObservationType•DescribeResultModel•Register Sensor•InsertObservation

118


SOSSensor Data Consumer

SOSSensor Data Consumer

119


SOSDiscover Services

Service Discovery is accomplished by using one or more OGC Catalog Service (CS-W) instances.

Some discovery informations:• Time period of observations• Phenomena captured by observationsp y• Spatial extent of observations• GML names used in observation offerings• GML descriptions used in observation offerings

SOSDiscover Observations

Observation discovery happens at the service level. The service capabilities document includes detailed information about all of the offerings that are available from a service.

Thi b d t f th t t G tOb tiThis can be used to further target GetObservationrequests.

120


SOSDiscover Sensor Metadata

Sensor metadata can be retrieved for any sensor that is advertised in an observation offering using the DescribeSensor operation.

This will return a SensorML or TML document with detailed information about the sensor.

SOSDiscover Sensor Observations

Sensor observations are obtained using the GetObservation operation. This operation supports a selection mechanism that supports subsetting the observations that will be returned from a call to GetObservation. GetObservation allows the client to filter a large dataset to get only the specific observations that are of interest.

121


SOSDeveloping @ SUPSI - IST

http://52north.org

SOSDeveloping @ SUPSI - IST

ER - SOS

122


SOSRoadmap @ SUPSI - IST

WPS WCS WMS WFSSOSWPS WCS WMS WFSSOS

GRASS

Links

O G ti l C tiOpen Geospatial Consortiumhttp://www.opengeospatial.org/

52°Northhttp://52north.org/

GALEON(Geo-interface to Atmosphere, Land, Environment, Ocean netCDF)

http://galeon-wcs.jot.com

123

Session III – Mobile GIS and infrastructure

ICAD-GEO: studio di fattibilità per la realizzazione di un progetto per la realizzazione di una "infrastruttura per la cooperazione

applicativa dei dati geografici"

Marco Negretti

Politecnico di Milano, Polo Regionale di Como

125

M. Negretti, POLIMI – ICAD-GEO: studio di fattibilità per la realizzazione di un progetto per la realizzazione di una “infrastruttura per la cooperazione applicativa dei dati geografici”

Comitato italo-svizzero per la geoinformazione

Les Marécottes, 16 - 17 giugno 2008

ICAD-GEO: studio di fattibilità per la realizzazione di un progetto per la

realizzazione di una "infrastruttura per la cooperazione applicativa dei dati geografici"

Marco Negretti

Centro Interregionale

Centro Interregionale di coordinamento e documentazione per le informazioni territoriali

“Deliberare una strategia unitaria e definire normedi comportamento comuni fra le regioni e leprovince autonome nella materia delleinformazioni aventi rilevanza territoriale e conparticolare riferimento alla programmazione dellaproduzione cartografica alla sperimentazione diproduzione cartografica, alla sperimentazione dinuove tecniche, alla disciplina dei lavori e deicollaudi”

http://www.centrointerregionale-gis.it/

127


LOTTO 4: ICAD-GEO

LOTTO 4: ICAD-GEO studio di fattibilità per la realizzazione di unstudio di fattibilità per la realizzazione di un

progetto per la realizzazione di una "infrastruttura per la cooperazione applicativa dei dati

geografici"1. Definizione di una piattaforma di cooperazione applicativa in ambito geograficopp g g2. Indagine sul riuso della

"Piattaforma Interregionale ICAR"

LOTTO 4: ICAD-GEO

LOTTO 4: ICAD-GEO3. Indagine sul riuso (con riferimento alla cooperazione applicativa) dei sistemi:cooperazione applicativa) dei sistemi:

- Sigmater- SITAD- InterGeo- Pr5CIPEPr5CIPE- Apulie- SICS- TopoCore

128


LOTTO 4: ICAD-GEO

LOTTO 4: ICAD-GEO4. Predisposizione di uno stack tecnologico "Open Source" per la gestione e la pubblicazione dei dati geografici e dei data base topografici

LOTTO 4: ICAD-GEO

Unità di ricerca coinvolte- Università degli Studi di Palermog

- Politecnico di Milano, Polo Regionale di Como

- Università degli Studi di Cagliari, Dip. di g gIngegneria Strutturale, Sezione di Topografia

129


Geoservizio e Interoperabilità

InteroperabilitàDiversi aspettiDiversi aspetti- modelli dati- dal punto di vista geometrico

> dati catastali e DB topografici- per il progetto si è fatto riferimento aspetto diper il progetto si è fatto riferimento aspetto di interoperabilità legato allo scambio di dati tramite geoservizi: direttiva INSPIRE => WMS 1.3

Stack Tecnologico

stack tecnologico "Open Source"Predisposizione di uno stack tecnologico "Open Source" per la gestione e la pubblicazione dei datiSource per la gestione e la pubblicazione dei dati geografici e dei data base topograficiPredisposizione di tre ambienti di test per la realizzazione del geoservizio:- MapServer + PostgreSQL/PostGIS

GeoServer + PostgreSQL/PostGIS- GeoServer + PostgreSQL/PostGIS- ArcSDE + Oracle, PostgreSQL/PostGISPer la gestione dei metadati:- GeoNetwork, RNDT, Deegree CS-W

130


Geoservizio - Polo di Como

Geoservizio- MapServer + PostgreSQL/PostGIS

- MapServer 5.0 => WMS 1.1- MapServer 5.2 (luglio 2008) => WMS 1.3

Geoservizio - WMS 1.3

WMS 1.3Società / Nome software versione server client

Cadcor - http://www.cadcorp.com/Cadcorp SIS Active Server Component 6.2 si sip pCadcorp SIS Map Server 6.2 si si

CARIS - http://www.caris.com/CARIS Spatial Fusion Enterprise 4.2.1 si si

con terra- Applied Information Technologies - http://www.sdi- suite.de/sdi.suite mapClient 2.1 no si

CubeWerx - http://www.cubewerx.com/CubeSERV Cascading Web Map Server 4.6 si noCubeXPLOR 4.6 no siGoogle Earth Extension for WMS 1.0 si no

Generic Logic - http://www.genlogic.com/GLG M S 2 10 iGLG Map Server 2.10 si no

Manifold Net - http://www.manifold.net/Manifold System 6.50 si si

Newgrove - http://www.newgrove.com/Address Caf 4.2 si no

SuperMap GIS Techonologies - http://www.supermap.com.cn/SuperMap Deskpro 5.3 no si

http://www.opengeospatial.org/resource/products/byspec

131


Geoservizio - Polo di Como

Geoservizio- MapServer => realizzazione di geoservizi conformi alla direttiva INSPIREconformi alla direttiva INSPIRE

- geoservizio con dati di test a livello regionale e comunale della Regione Sardegna WMS, WFS e WCS

- geoservizio per la distribuzione dei DB t fi i l 1 2000 d ll R itopografici a scala 1:2000 della Regione LombardiaWMS, CS-W

Cataloghi metadati

MetadatiG N t k tt i t i l FAO- GeoNetwork => progetto internazionale: FAO

- RNDT => progetto nazionale: CNIPA

132


Cataloghi metadati

GeoNetwork- è stato sviluppato dalla FAO (Food and Agriculture Organization) con la collaborazione diAgriculture Organization), con la collaborazione di altre Agenzie delle Nazioni Unite (UNEP, OCHA, OMS), per facilitare l’archiviazione e lo scambio dei metadati relativi ai dati geografici

- standard ISO 19115, Dublin Core, FGDCO GIS C t l S i I l t ti- OpenGIS Catalogue Service Implementation Specification (CS-W )

http://geonetwork-opensource.org

http://www.fao.org/geonetwork

Cataloghi metadati

GeoNetwork- indipendente dalla piattaforma HW/SW

- sviluppato in Java - PC o server- su Windows, Linux e Mac OS X.

- licenza GPL

133


Cataloghi metadati

RNDT - Repertorio Nazionale dei Dati Territoriali- Il portale realizzato dal CNIPA (CentroIl portale realizzato dal CNIPA (Centro Nazionale per l'Informatica nella Pubblica Amministrazione) ha lo scopo di fornire una struttura per l'inserimento e la consultazione dei metadati relativi ai dati territoriali disponibili in ambito nazionale nei diversi enti della pubblica

i i t i ( i i i t ità diamministrazione (regioni, province, autorità di bacino, comunità montane....)

http://www.cnipa.gov.it/

Cataloghi metadati

RNDT - Repertorio Nazionale dei Dati TerritorialiIn fase di test e non completo di tutte leIn fase di test e non completo di tutte le funzionalità previste

- linguaggio di sviluppo del sito: PHP- navigazione/interrogazione dei dati:

UMN MapServer e Ka-Mapd t b P t SQL/P tGIS- database: PostgreSQL/PostGIS

- Licenza: da definire

134


Valutazione performance

INSPIRE - Draft Implementing Rules for Discovery and View Services (IR1)

17-12-2007


Come effettuare effettivamente i test...- PerformancePerformance

- quanti layer?- Availability

- ok- Capacity

- quanti layer?- intervallo di tempo

135



Riferimeto test: documento di INSPIRE- software utilizzato per simulazione traffico:software utilizzato per simulazione traffico:

Apache JMeter

http://jakarta.apache.org/jmeter/

136


WebGIS & context aware mobile GIS

Prof. Dr. Maria Brovelli


137

M. Brovelli, POLIMI – WebGIS & context aware mobile GIS

Interoperability and standards: overview of activities in the last yearthe last year

Politecnico di Milano – Polo Regionale di Como(Laboratorio di Geomatica)

M. A. Brovelli

Summary

1 Web and Mobile GIS in Archeology (MetaSudans1. Web and Mobile GIS in Archeology (MetaSudanswebGIS, Spina Verde and Metasudans NamGIS,RiCoMGIS)

2. Italian SDA

3. The IDE-Univers project

4 “e Collaboration for DGPS/GPS data distribution and4. “e-Collaboration for DGPS/GPS data distribution andreceiver device evaluation”

139


Archeomedsat

It is a project of MIUR (Ministry of Education, Universityand Research), for years 2005 to 2008, in the frame ofth It li FIRB (F d f I t t i th B i

archaeology

the Italian FIRB (Fund for Investments in the BasicResearch).

Its title is: “ArcheoMedSat: project and experimentationof satellite survey and web GIS to bring outarchaeological monuments and sites of theMediterranean, between East and West”.

MINISTERO DELL'ISTRUZIONE, DELL'UNIVERSITÀ E DELLA RICERCADipartimento per la Programmazione il Coordinamento e gli Affari Economici

Servizio per lo sviluppo e il Potenziamento delle Attività di ricerca (SSPAR) FIRB 2003 D.D. 2186-Ric 12 dicembre 2003

MetaSudans WebGIS

archaeology

Web Site: http://geomap.como.polimi.it:8080/metasudans/

user: firb01passwd: archeomedsat

140


archaeology

MetaSudans and Spina Verde NamGIS

• NAMgis is the acronym of Nomadic Aware Mobile GIS• It is an open source context aware mobile GIS especially

archaeology

• It is an open-source context-aware mobile GIS especiallytargeted at small screen and CPU limited handhelddevices.

• NAMGIS supports the import of GML geospatial dataand its display by means of a Web-based interfaceaugmented with context and location-awarefunctionalities. These features are based on theacquisition of sensor data coming from a GPS receiverand an RFID (Radio Frequency IDentification) readerassociated to the handheld device.

141


MetaSudans and Spina Verde NamGIS

• NAMGIS is a Java client-server platform running on topof MapServer Java Mapscript PostgreSQL/PostGIS and

archaeology

of MapServer Java Mapscript, PostgreSQL/PostGIS andthe Tomcat servlet container.

• Internally, it is composed of SAF (Situation AwareFramework), which supports the acquisition andelaboration of context data, and of NAMGIS Core, themobile GIS which provides an internationalized, context-adaptable Web interface. These two components can bealso used independently and will be both released withan open source license (LGPL for SAF, GPL forNAMGIS Core).

RIComGIS

• RiCOMGIS is the acronym of Rich Client Open sourceMobile GIS

archaeology

Mobile GIS

• Available at: http://geomap.como.polimi.it/RiCOMGIS/

142


Map Generator (theGIS engine) isimplemented in Java, itmakes use of UMN

archaeology

MapServer JavaMapScript

RiCOMGIS Fron-End(the GUI) is a FlashGUI; it bases onO L l d iOpenLaszlo and isloaded by a server-resident application(Front-End Producer)

Italian SDI

SDI

• Metadata: analysis of ISO/ INSPIRE/ Italian specifications

• Geocatalogs: GeoNetwork, CNIPA

• Implementation of OGC WMS INSPIRE compliant for 2k geodatabases compliant with the Italian data model

143


IDE-Univers

Ide-Univers

IDE-Univers

http://www.ideunivers.eu

Aim: to implement an infrastructure of spatial data, for promoting accessibility and interoperability of a great amount of geographical (spatial) information, generated by universities and research centers

e-Collaboration for DGPS/GPS data distribution

e-Collaboration DGPS/GPS

It is a GIS internet collaborative environment allowing people to shareand assess their measured GPS data. For the presentation of datainteractive maps and related graphs are dynamically generated on-p g p y y gthe-fly.

Experts users distribute their high-accuracy DGPS data correspondingto specific points or paths (“calibration field”); those data are taken asreference (“the ground truth”) by the system.

Common users evaluate their low-accuracy GPS receivers obtainingindices computed from DGPS data and their measured oneindices computed from DGPS data and their measured one.

The system contains evaluation of accuracy estimations for differentGPS receivers. Related organizations and institutions obtain apractical foundation for evaluation of each brand of GPS receivers indifferent part of the world.

144


e-Collaboration for DGPS/GPS data distribution

Users upload data in NMEA, GPX or text format. Data are stored inPostgreSQL-PostGIS

e-Collaboration DGPS/GPS

By means of PHP Mapscript a Map Generation Engine is created,which produces interactive maps to present GPS data dynamicallywithout any manual operations by making use of Google map asbackground layer.

For the accuracy evaluation part, among other indices, the buffermethod is applied with the GPS and DGPS data as LINE whileerror ellipse is used for data as POINT.

In addition, users are asked to give information about their GPSreceivers, which is consequently stored in a database and, incombination with assessed results, exploited for statistics aboutdifferent kinds of devices.

145


slaxGIS – a GIS-oriented live USB system

Eugenio Realini


147

E. Realini, POLIMI – slaxGIS: a GIS-oriented live USB system

slaxGISslaxGISa GIS-oriented live USB system

Eugenio RealiniEugenio RealiniPolo Regionale di Como – Laboratorio di Geomatica

17 / 06 / 08 - Lausanne - Meeting 2008 del Comitato scientificoitalo-svizzero per la geoinformazione

slax a live CD/USB Linux system

http://www.slax.org

developed by Tomáš Matějíček

portable Slackware-based Linux operating system

modular approach

p g

high compression rate ( base system < 200 MB )

complete working environment that can store changesmade to the filesystem (new data, custom configurations, ...)

149


slaxGIS a custom slax system

new slax modules meant to be added to slax 6.0.x live USB,built at Laboratorio di Geomatica

Desktop GIS, webGIS, datasets and dependencies:

GRASS MapServeruDig ChameleonOpenJUMP PIROL edition

GDAL/OGRS fSpearfish Proj.4Itasca PHP

Apache Web Server[...]

http://geomatica.como.polimi.it/software/slaxGIS

slaxGIS system installation

requirements: USB flash disk (1 GB minimum)USB-bootable computer

download: slax 6.0.x base system from slax.org (.tar file )slaxGIS modules from geomatica.como.polimi.it

extract: the slax base system on an empty USB keythe slaxGIS modules to the root dir of the samedevice (this will add .lzm files to /slax/modules)

run: /boot/bootinst.sh as root(on Linux systems)/boot/bootinst.bat (on Windows systems)in order to make the USB stick bootable

150


slaxGIS how to boot the system

nowadays most desktop PCs and laptops can be booted froma USB flash disk

usually you need to access the BIOS of the host computer andchange its boot order so that it looks for bootable USB devicesbefore booting from an internal hard disk

in order to do that it is often required to have already insertedthe flash disk in a USB port when the system is powered up

every time you boot slax you can choose if you want tostart a “persistent changes” or an “always fresh” session

once the live system has booted correctly, all the internal drivesare mounted, so that they can be browsed from the live system

slaxGIS demo!

... so let's try and continue this slideshow

from within slaxGIS!

151


slaxGIS slax modules

modules are LZMA-compressed archives ( .lzm )

tools used to decompress and compress archives and to converttools used to decompress and compress archives and to convertfrom various Linux packages formats to .lzm are provided withthe base slax system:

lzm2dir (decompress) tgz2lzm (from Slackware .tgz )dir2lzm (compress) deb2lzm (from Debian .deb )

rpm2lzm (from Red Hat .rpm )

Modules can be added/removed on the fly from within the systemwith a few clicks

slaxGIS GRASS

Free and Open source GIS

Geographic Resources Analysis Support System

Written in: C/C++ Makes also use of Tcl/tk, Python

Supports multiple geographic formats through GDAL/OGR

http://grass.osgeo.org

Uses Proj.4 to manage projections

Can exploit PostgreSQL/PostGIS, MySQL, SQLite, ...

152


slaxGIS GRASS

Import/Export

Vector/raster analysis

Rasterization / vectorization

Hydrologic modeling

Wildfire modeling

LiDAR analysis

Overlay

Queries

Geometry management

Map algebra

Neighborhood analysis

LiDAR analysis

Geostatistics

Optical image processing

3D analysis

...

Interpolation

Network analysis

Datum shifting

Solar radiance & shadows

Terrain analysis

slaxGIS GRASS dataset: Spearfish

This dataset is made of a GRASS locationthat contains data in raster vectorthat contains data in raster, vectorand point format

Useful to start working with GRASS withouthaving to worry about the creation of a new locationand mapset

153


slaxGIS MapServer

Development environment for webGISapplicationsppInteractions

navigation (pan, zoom in, zoom out, predefinedviews)queries (single or multiple ones)

Generation of dynamic pages by means ofM S CGI

http://mapserver.gis.umn.edu/

MapServer CGIMultiple formats support through GDAL/OGRProjections management through PROJ.4

slaxGIS MapServer / Chameleon

Chameleon uses MapServer as itsmain mapping enginemain mapping engine

WebGIS development environmentwith a modular approach

WebGIS functionalities are introduced by means of predefined (but customizable) widgets

Makes use of HTML CSS JavaScript XML PHP

http://chameleon.maptools.org/

Makes use of HTML, CSS, JavaScript, XML, PHP technologies

A working chameleon example is included (Itasca dataset)

154


slaxGIS uDig


User-friendly Desktop Internet GIS

JAVA application: platform independent

Allows to load and edit local files and to load remoteones through OGC standard protocols, WMS/WFS.

http://udig.refractions.net/

ones through OGC standard protocols, WMS/WFS.

slaxGIS OpenJUMP (PIROL edition)


Java Unified Mapping PIatform

JAVA application: platform independent

PIROL edition includes various plug-ins such as thoseneeded to access rasters, load NMEA files, ...

http://www.pirol.fh-osnabrueck.de/pirol-openjump.html

needed to access rasters, load NMEA files, ...

Allows to load and edit local files and to load remoteones through OGC standard protocols, WMS/WFS.

155


slaxGIS PostgreSQL / PostGIS

PostgreSQL is a free and Open sourceobject-oriented relational DBMSobject-oriented relational DBMS

Highly customizable

At the moment a GUI is not provided within slaxGIS

PostGIS adds support for geographic objects to the

http://www.postgresql.org/

PostGIS adds support for geographic objects to thePostgreSQL object-relational database.

http://postgis.refractions.net/

Document license

This work is released under a'Creative Commons License'Creative Commons License

http://creativecommons.org/licenses/by-sa/3.0/

156

Session IV – Added value of the 3rd dimension through enriched semantics

Update on LaSIG’s research activities. Some more semantics into the 3rd D: some insights and questions

Prof. Dr. François Golay



157

F. Golay, EPFL – Update on LaSIG‘s research activities. Some more semantics into the 3rd D: some insights and questions

Terza riunione delComitato scientifico italo-svizzero per la geoinformazione

Les Marécottes – 16/17.6.2008

Update on LaSIG’s research activities.Some more semantics into the 3rd D:

some insights and questions

François GolayEcole Polytechnique Fédérale de Lausanne

[email protected]

The GIS Research Lab develops research axes focusing on:– decision support on space and land related issues

– exploratory spatial analysis and geoinformationvisualization

– promoting and assessing added value and usabilityp g g yof geographic information systems and data

– geospatial data infrastructures and information sharing

Clustering of a LIDAR 3D points cloud

Dynamic interfaces forexploratory spatial analysis(cultural anthropologyat Val d’Hérens, Switzerland)

pof a forest cover

159


Spatial dimension in cultural anthropologyCLAN project

Abram Pointet, LASIG - EPFL

• HCI for interactive data mining• Multi-dimensional exploration

Aerial LIDAR offers new opportunities to model forests and landscapes in combining multiple position and signal data

Clustering of a LIDAR 3D pointscloud of a forest cover

D’après Gilles Gachet, LASIG 2005Source des données: Swisstopo, MNS et MNT

160


Study of the genetical diversity of animal speciesin Europe (ECONOGENE)

Thesis of Dr. Stéphane Joost,laureate of the AAG first Garrison Award for excellence in quantitative Geography

Visualization and exploration in the 3rd dimensionINTER seed money project: Perrochet/Pleinciel

• Legacy of a collection of postcards:

30’000 aerial photographs covering Switzerland over the years 1960-1964

• Intuitive « geocontextualization » « geocontextualization » on virtual globe

• Temporal evolution analysis tool of the territory

161


But virtual reality encompasses many questions…

… Why build a new highway if there is no traffic at all !?

Four lane road design study, Kentucky2000 Joel Brumm

limited information in IS makes artificial settings necessary for the scenery

Que vous faut-il donc de plus, cher Monsieur !?

• des infrastructures de données géographiques assurant une authentique ouverture (si ce n’est gratuité) des q ( g )données et des services géolocalisés

• au-delà de l’ouverture des données et des services:des moteurs ouverts !?

• au-delà de l’attractivité et de l’utilisabilité d’un gadget(effet « scoubidou »,à l’exemple de certaines cyber cities) :à l exemple de certaines cyber cities) :

vers une utilité reconnue !?

162


Indicators of urban development based on different urban models and data

DTM, TIN , … Aerial images GIS and cadastral data

Rules, instructions, …Raw LIDAR data Standards, …

Identify and evaluate different users’ needs (utility/usability) regarding several urban indicators of development/durabilityEvaluate forms of 3D urban representation correctly adapted to the visualisation of 3D data (spatial, thematic and topological dimensions)

Claudio Carneiro, LASIG - EPFL

Multiscale geomorphological analysis• Geomorphological / geological features are strongly

related to scale.• Using high resolution DEM and wavelet generalization,

geological features are identifiedgeological features are identified.• The wavelet transform is

a local spectral analysis toolswith compact support:

e.g.: identification of karstic faults

• Features are filtered (ex-tracted) at a certain wavelet decomposition level (depen-ding on their local scale)

Thesis of Michaël Kalbermatten

163


Virtual globes:3D spatio-temporal exploration

Jens’Presentation :Patrouille des glaciers

LASIG’s presentations

• Eduardo Camacho-Huebner:Ontologies evolution from social sciences needs to interoperability opportunities

• Claudio Carneiro:Matching 3D city models and urban indicators to users’ needs

• Michaël Kalbermatten:• Michaël Kalbermatten:Landscape characterization using wavelet detail coefficients

• Jens Ingensand:3D web interfaces to the “Patrouille des glaciers” race

164


Matching 3D city models and urban indicators to users’ needs

Cláudio Carneiro



165

C. Carneiro, EPFL – Matching 3D city models and urban indicators to users‘ needs

Matching 3D city models and urbanindicators to users’ needs

Claudio Carneiro, François GolayEcole Polytechnique Fédérale de Lausanne (EPFL)

GIS Laboratory (LaSIG)[email protected] ; [email protected]

Sujets

• Introduction

Modèles urbains et indicateurs 3D: Sujets

• Présentation de la méthodologie• Indicateurs de développement et durabilité• Identification des besoins utilisateurs (interviews)• Applications 3D urbaines• Reconstruction de modèles 3D urbains• Quelques exemples d’indicateurs urbains (inclus les

différentes propositions de visualisation des indicateurs étudiés et présentés)

• Conclusions

167


Modèles urbains et indicateurs 3D: Introduction

Buts du projet

Pour démontrer l’utilité et l’utilisabilité réelles de ces modèles urbainsnumériques:

• développer des processus d’acquisition, d’agrégation et de présentation d’indicateurs de l’évolution urbaine dans une perception tridimensionnelle de la ville

• estimer la plus-value pour la compréhension des phénomènes • estimer la plus value pour la compréhension des phénomènes urbains

• aide à la prise de décision

Magnifique vue de Salzburg !...


… mais que peut-on bien en faire ?!

168


On peut bénéficier d’un modèle urbain 3Dsans même passer par la représentation 3D !

Exemple:


Evaluation des immissions du bruit routier –

le modèle de simulation pourrait utiliser les points LIDAR bruts…


Résultat de la modélisation satisfaisant…

… mais pourquoi pas une interface

exploratoire 3D !?

169


Modèles urbains et indicateurs 3D: Présentation de la méthodologie

Intérêt et analyse exploratoire de l’information visuelle 3D et mise en place d’indicateurs de développement/durabilité (pour chaque utilisateur)

Présentation de la méthodologie

pp (p q )

Utilité(pertinence de

l’i f ti 3D)

Utilisabilité(étude cognitive d i t f d

Il faut tout d’abord évaluer… … et après …

Développement de formes de

représentationspécifiques l’information 3D) des interfaces de

visualisation 3D proposés)

spécifiques (interfaces 3D)

Modèles urbains et indicateurs 3D: Indicateurs de développement et durabilité

Un indicateur constitue une interprétation empirique et indirecte de la réalité…

Résultat d’une sélection pertinente ou d’une agrégation de données

Les indicateurs proposés doivent aussi permettre

Résultat d une sélection pertinente ou d une agrégation de données…

Réduction de l’information favorise une meilleure compréhension des phénomènes complexes !

au moins l’un des trois types de comparaison suivants (Joerin et al., 2005):

1 - évaluation du phénomène considéré par rapport à un objectifnormé ou tendanciel2 - comparaison de différents lieux spatiaux3 - comparaison de différentes périodes temporelles

170


Identification des « besoins utilisateurs » (interviews)

1) Différents domaines de travail des utilisateurs concernés:

Modèles urbains et indicateurs 3D: Identification des « besoins utilisateurs » (interviews)

L'analyse du sondage 3D montre qu'il existe de réels besoins à Genève de

modéliser des données en 3D. Pour une meilleure organisation et compréhension des

besoins de chacun, les résultats du sondage ont été classés en 6 domaines distincts:

• Architecture, urbanisme et aménagement du territoire

• Environnement et énergie

• Aéroport International de Genève

• Bruit et rayonnement

• Services routiers et trafic

• Entreprises privées et divers

2) Evaluation préliminaire des domaines d’intervention (quelques exemples):

• Architecture, urbanisme et aménagement du territoire : intégration de nouveaux projets d’architecture et réalité virtuelle; défense du patrimoine existant; impacte de nouveaux bâtiments dans l’environnement bâti

Modèles urbains et indicateurs 3D: Identification des « besoins utilisateurs » (interviews)

existant; impacte de nouveaux bâtiments dans l environnement bâti existant; intégration de « connaissance » urbaine dans des modèles 3D urbains; …

• Environnement et énergie: dérivation du volume et surface des bâtiments construits; analyse de la consommation énergétique des bâtiments construits; ...

• Aéroport International de Genève: dérivation des plans d’obstacles autour de la zone de sécurité de l’aéroport; simulations de vols (approche et atterrissage); …

• Bruit et rayonnement: protection contre hauts niveaux de bruit; Bruit et rayonnement: protection contre hauts niveaux de bruit; protection contre la pollution bâti; …

• Services routiers et trafic: évaluation et analyse du bruit et pollution causées par le trafic routier (façades de bâtiments); …

• Entreprises privées et divers: situations médicales de secours (atterrissage d’hélicoptères); …

171


Modèles urbains et indicateurs 3D: Applications 3D urbaines

Extractions d’indicateurs/informations

Sources de données

laserNDR0 - Modèle Digital de Terrain (2 5D)

Différents niveaux de détail de représentations 3D (évaluation et intérêt)

Niveaux de détail de représentations 3D (NDR)

Modèles urbains et indicateurs 3D: Différents niveaux de détail de représentations 3D

Plus de précision

cadastre, laser aérien

de Terrain (2.5D)

NDR1 - bloques de bâtiments sans structure de toits (3D)

NDR2 – bâtiments texturés avec des structures de toits (3D)

laser aérien et terrestre, photogrammétrie

Photogrammétrie NDR3 – bâtiments Architecturales détaillés (3D)

NDR4 – intérieur des bâtiments (3D)

get laser terrestre (façades de bâtiments),approches hybrides

laser terrestre

Selon les normes proposées par « CityGML »

172


Différents niveaux de détail de représentations 3D (évaluation et intérêt): trois niveaux de détail supplémentaires proposés dans le cadre de la 3D à Genève

L’évaluation menée à Genève nous a conduits à insérer trois NDR supplémentaires (par rapport à la norme « CityGML »), car les façades

Modèles urbains et indicateurs 3D: Différents niveaux de détail de représentations 3D

pp (p pp y ) çde bâtiments peuvent être aussi classifiées et visualisées comme :

Modèles urbains et indicateurs 3D: Reconstruction de modèles 3D urbains

Sources de données

• Vectorielles 2D• Raster 2.5D

é é é• Attributaires stockées Base de Données: informations altimétriques• Laser aériens (LIDAR) et terrestres: points bruts

• Photos aériennes (orthophotos)et terrestres

173


Modélisation urbaine 3D à partir des données cadastrales

Les données cadastrales 2D peuvent être utilisées avec un attribut hauteur pour modéliser les objets d’une façon trop généralisée (comme ensemble de bloques) …


+ attribut hauteur chaque bâtiment

mais surtout pour… mais surtout pour mieux caller les données issues de la technologie laser aéroporté (LIDAR),notamment en définissant une empreinte au sol plus précise des bâtiments modélisés ! [Schwalbe et al., 2005]

Technique appliquée pour la mise en

place d’un modèle


urbain de surface 3D (terrain, bâtiments et

maisons) à partir de données laser

LIDAR en brut, pour ultérieur calcul des

indicateurs de visibilité (isoviews)

et d’exposition et d’exposition solaire sur les façades des bâtiments

174


Modèle 3D Urbain Numérique d’Haute Précision


Simulation de la morphogenèse urbaine par un système multi-agents

(en collaboration avec Prof. Corinne Plazanet, EPFL)

Analyse des Modèles Numériques de Surface (MNS) à partir des données laser

Modèles urbains et indicateurs 3D: Quelques exemples d’indicateurs urbains

Images raster: dérivation de cartes de visibilité et d’exposition solaire (input

concernant le degré de satisfaction des habitants pour de nouveaux bâtiments à

construire dans la ville)

Information urbaine additionnelle: système multi-agents

Simulation (implémentation computationnelle ) du développement urbain (intelligence artificielle)

Modèle urbain 3D Localisation de nouveaux bâtiments (représentation 3D)

175



Cartes de visibilité (ISOVISTES)



176






177


Localisation de nouveaux bâtiments: visualisation 2D(en collaboration avec Prof. Corinne Plazanet, EPFL)


Exposition solaire sur les façades des bâtiments(en collaboration avec Eugenio Morello, Senseable City Laboratory, MA, USA)


178


Modèles urbains et indicateurs 3D: Quelques exemples d’indicateurs urbains BlackBox

Radiation solaire par bâtiment (W/m2): visualisation 3D


179


Radiation moyenne par façade (W/m2): visualisation 2D


Technique appliquée pour la mise en


Radiation sur les toits des bâtiments – Image Segmentation

pour la mise en place d’un modèle urbain de surface 3D des toits des

bâtiments et maisons, à partir de

données laser LIDAR en brut (par segmentation) pour

le calcul, par e ca cu , paexemple, de

l’exposition ou radiation solaire sur

les toits des bâtiments

180



Calcul des pentes

des toits…


Calcul del’orientationdes toits…

181


Radiation sur les toits (W/m2): visualisation 2.5D


Sélection des toits mieux adaptés à recevoir des panneaux solaires(projet en développement, en collaboration avec Gilles Desthieux, LEEA, Geneva)


Segmentation des toits (surface)g ( )

Segmentation des toits (pente)

Segmentation des toits (orientation)

Segmentation des toits (radiation)

182


Certains indicateurs ne sont même pas visuellement représentés… comme par exemple les indicateurs relatifs au calcul global de dépenses énergétiques par ville (projet en développement)


LT (lighting andthermal) model

Ratti et al. [2004]

Modèles urbains et indicateurs 3D: Conclusions

L’élaboration d’un prototype de modèle urbain 3D pour la ville de Genève (dans certains cas aussi à Lausanne), avec proposition de plusieurs indicateurs (surtout morphologiques et environnementaux), qui fera l’objet d’ ét d d’ tilité t d’ tili bilité d ti é à t t d iè d’une étude d’utilité et d’utilisabilité destinée à tester de manière rigoureuse l’adéquation des représentations et visualisations (interfaces) proposées avec les utilisateurs « métier »

On attend de ces travaux aussi bien des résultats spécifiques sur les besoins de Genève/Lausanne en matière de modélisation urbaine 3D que des résultats d’intérêt plus général sur la nature des processus de conception et d’évaluation à mettre en œuvre pour l’élaboration de conception et d évaluation à mettre en œuvre pour l élaboration de modèles urbains 3D

Merci pour votre attention!!!

183


Landscape characterization using wavelet detail coefficients

Michaël Kalbermatten



185

M. Kalbermatten, EPFL – Landscape characterization using wavelet detail coefficients

High resolution DEM generalization

Landscape characterization using wavelet detail coefficients

the landslide case study

Michael Kalbermatten – LaSIG-EPFL

[email protected]


Contents


Wavelets, why? how? results?

Low pass coefficients

High pass coefficients – Inverse Wavelet transform

Landslide case study

Further work

187




Why?

− High resolution DEMs contain local landscape information and represent micro-relief (but contain also meso and macro landscape information)

− Interests in meso and macro landscape => Generalization

Generalization using wavelets, why?

− Conceptually, wavelets should be a good generalization filter:

Local analysis => adaptive to the structure

− Assessment through comparison with other techniquesg p q


Wavelet theory (1) The Wavelet transform (WT) is a local spectral analysis tool with compact support. This is one of the main differences between the Fourier transform and the Wavelet transformFourier transform and the Wavelet transform.

Fourier:

188



Wavelet theory (2) Wavelets are local spectral analysis tools with compact support.

Wavelet:


Wavelet theory (3) A wavelet defines a scale function (and vice-versa).

The spectral domain which isn't covered by the different scale–time translations of the wavelet are covered by the scale function.

In discrete imaging, the wavelet defines a high pass filter in the Fourier space.

In discrete imaging, the scale function defines a low pass filter in the Fourier space.

The Fourier domain is used to compute the spatial convolution of the p pfilter with the image (a convolution in the spatial space = a multiplication in the Fourier space => much easier!)

189



Wavelet theory (4) We know the scale function (B-spline basis of third degree):

Convolution formule of the scale function: ��x / 2�= �2∑ h�k ��x− k�

h(k) is the low pass filter.

Convolution formule of the wavelet function:

g(k) is the high pass filter.

H(ω) and G(ω) are the impulse response in the Fourier space of h(k)and g(k) => multiplication...

∑k ��

��x /2�= �2∑k��

g �k ��x− k �

In two dimensions (in imagery...), the wavelet transform can be separated. First, the filters are applied on the lines, then the filters are applied on the columns (Mallat).


Wavelet theory (5)

190



Wavelets results – Second decomposition


Low pass coefficients - Results

2nd decomposition(resolution: 4m)

191




3rd decomposition(resolution: 8m)



4th decomposition(resolution: 16m)

192








193






Elevation and slope analysis – Scatterogram

194



High pass coefficients (1)

InverseWT


High pass coefficients (2) Low pass coefficients of a specific decomposition level are replaced by zeros.

Filters (by autocorrelation methods are computed) and applied.

The result is an image of the size of the original surface (and with its resolution).

A lot of different possibilities in wavelet recomposition, e.g. first coefficients can be replaced by zeros to suppress high-scale noise, ...etc.

195



High pass coefficients - Results

2nd recomposition(coefficients 1 to 2)



3rd recomposition(coefficients 1 to 3)

196




4th recomposition(coefficients 1 to 4)




197








198



Landslide case study – Theoretical analysis

Modelization of a simple virtual landslide.

Filtering with wavelet transform.

Reconstruction of high pass coefficients.


Landslide case study – Theoretical analysis - Results

Low pass results

1st decomp.(resolution 2m)

~500m

199




Low pass results

2nd decomp.(resolution 4m)

~500m



Low pass results

3rd decomp.(resolution 8m)

~500m

200




Low pass results

4th decomp.(resolution 16m)

~500m



Low pass results


~500m

201




Low pass results


~500m



Low pass results


~500m

202




Low pass results


~500m



High pass results

~500m2nd recomposition(coefficients 1 to 2)

203




High pass results

~500m3rd recomposition(coefficients 1 to 3)



High pass results

~500m4th recomposition(coefficients 1 to 4)

204




High pass results




High pass results


205




High pass results




High pass results


206




High pass results – Only coefficients from 8th decomposition level

~500m


Landslide case study – Applied analysis

Analysis on 1m resolution DEM in Val de Travers – Neuchâtel – CH

Helicopter laserscanning, TIN interpolation

207



Landslide case study – Applied analysis

Wavelet transform, decomposition until the 8th level.

Analysis of the reconstruction of the detail coefficient.

Identification of multi-scale structural features.

On site verification of detected features


Landslide case study – Applied analysis – Detail coefficients

Level 1 to 2 Level 1 to 3

208



Landslide case study – Applied analysis - Comments

Identification of micro structure folds due to landslide motion

On site:

− Many micro structures

− Folds frequencies match with detail level(1 to 2 and 1 to 3)




209



Landslide case study – Applied analysis - Comments

In deposit zone: identification of the bigger bulges

In scarp zone:

− Main streams

− Water flow modelof landslide




210



Landslide case study – Applied analysis – Global comments

Identification of main landslide features: scarp and deposit zone

All micro structural elements are embedded in bigger structure

When the resolution of a specific level is bigger then the feature, this one is not represented by the coefficient reconstruction any more, e.g. 8th level of decomposition:


Further work

Increase the complexity of the virtual landslide in order to understand the effect of wavelet generalization on geological features.

Application of denoising so as to isolate specific features.

Prove the conceptual framework: relation between scale (wavelets) and multi-scale geological features.

Thank you!

211


3D web interfaces to the “Patrouille des Glaciers” race

Jens Ingensand



213

J. Ingensand, EPFL – 3D web interface to the „Patrouille des Glaciers“ race

POLY PDGPOLY-PDG

Patrouille des Glaciers2008

La Patrouille des glaciers

Z tt V biZermatt – Verbier Longueur: 53 km

110 km effort Dénivellation: + 3994 m

Arolla – VerbierLongueur: 26 km

53 km effort53 km effort

Dénivellation: + 1881 m

215


La Patrouille des glaciers

Z tt V biZermatt – Verbier Longueur: 53 km

110 km effort Dénivellation: + 3994 m

Arolla – VerbierLongueur: 26 km

53 km effort53 km effort

Dénivellation: + 1881 m

L‘EPFL à la Patrouille des glaciers

U i i d h h (P f t A i t t )- Un quinzaine de chercheurs (Prof. et Assistants)- Une quinzaine d’étudiants Bs/Ms- Cinq doctorants

… et 16 Patrouilles!

216



M tt d- Maquette du parcours- Peaux de phoque- Mesures physiologiques- Transfert et stockage des données- Visualisation

- Microstations météorologiques


M tt d- Maquette du parcours- Peaux de phoque- Mesures physiologiques- Transfert et stockage des données- Visualisation

- Microstations météorologiques

217


Mesures physiologiques & géographiques

Obj tifObjectif

Obtenir des données physiologiques du coureur en temps réel, permettant l'optimisation de l'effort en course et à l'entraînement.

Méthodologie

Equiper les athlètes de différents capteurs capables deEquiper les athlètes de différents capteurs capables de mesurer les données physiologiques recherchées.


SpO2 }SpO2La saturation du sang en oxygèneIndication de la facilité à respirer.

Fréquence cardiaque

GPS

capteur basé sur le principe de l'oxymétrie colorimétrique à réflectance

=>paramètres physiologiques dérivés à partir de mesures optiques

}GPS

- lat/lon- altitude

218



Utilisation d’une caméra infra-rouge pour identifier le point de mesure idéal (le point le plus chaud)

Transfert et stockage des données

A i iti d d éAquisition des données :

Enregistrement des différentstypes de données (physiologiques, liés aux positions et liés au mouvements) par un data logger

(boitier électronique miniaturisé).

219




Balise 1

EPFL

1 fois / min

Serveur- reception des

données (Java)- stockage dans BD(Postgresql/PostGIS)

Balise 2 1 fois / min

220


Visualisation en temps réel

stand EPFL à Verbier- stand EPFL à Verbier- visualisation Google Earth - visualisation sur maquette physiquevisualisation données physiologiques

VerbierInternet

EPFL

- Visualisaition site web polypdg.epfl.ch

VerbierEPFL


visualisation Google Earth (mise à jour dynamique)visualisation Google Earth (mise à jour dynamique)

Creation kml dynamique- parcours- points de contrôle- position - altitude- données physio- interface (choix- interface (choix

du temps)

221



visualisation sur maquette physiquevisualisation sur maquette physique

Projection avec beamer


visualisation sur maquette physiquevisualisation sur maquette physique

Projection avec beamer

222



visualisation site web polypdg epfl chvisualisation site web polypdg.epfl.ch


visualisation données physiologiquesvisualisation données physiologiques

223


http://polypdg.epfl.ch

224

ISBN 978-3-906467-77-1 IGP Bericht Nr. 305

Vortrag Titelseiten · I modelli, il trasferimento dei dati, e l’interoperabilità nei GIS zione...

Documents

Transcript of Vortrag Titelseiten · I modelli, il trasferimento dei dati, e l’interoperabilità nei GIS zione...