vortrag titelseiten · i modelli, il trasferimento dei dati, e l’interoperabilità nei gis zione...
Post on 26-Aug-2020
2 Views
Preview:
TRANSCRIPT
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
2
3
4
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
6
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
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
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
Dati geospaziali Metadati
Infrastrutturetecniche
Basi giuridicheDirettive e Standards
Formazione e Ricerca
Geo-Servizi dibase
Politicatariffaria
Coordinamentoe rete di contatto
NGDINGDI
8
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
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
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
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
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
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
Rete elettrica Cavi elettrici
TubazioniAcquedotto
annodia-metro
dia-metro
Tipo
dia-metro
Anno costr.
Anno costr.
acquagas
acqua Rete distr. gas
Rete elettrica Cavi elettrici
TubazioniAcquedotto
annodia-metro
dia-metro
Tipo
dia-metro
Anno costr.
Anno costr.
acquagas
acqua Rete distr. gas
11
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
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
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
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
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
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
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
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
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
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
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
Una buona idea:NGDI
Dati geospaziali Metadati
Infrastrutture tecniche
Basi giuridicheDirettive e Standards
Formazione e Ricerca
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
Basi giuridicheDirettive e Standards
Formazione e Ricerca
Politica tariffaria
Coordinamento e rete di contatto
18
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 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
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
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
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
GISGIS
GIS interagenti possono essere realizzati a diversilivelli di funzionalità
• 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
GIS interagenti possono essere realizzati a diversilivelli di funzionalità
• 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
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
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
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
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)( )
Derivazione del formato
Lo standard svizzero INTERLIS
Realizzazione degli Standard ISO (TC 211) non solo per il trasferimento dei datip
23
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
Derivazione del formato
Lo standard svizzero INTERLIS
Derivazione del formato
Lo standard svizzero INTERLIS
24
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
Derivazione del formato
Lo standard svizzero INTERLIS
Lo standard svizzero INTERLIS
UML INTERLIS 2 Formato di trasferimento XML
Formato basato su GML è in preparazione
25
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
Lo standard svizzero INTERLIS
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
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
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
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
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
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
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
Limiti e prospettive (seguito)
Rete elettrica Cavi elettrici
TubazioniAcquedotto
annodia-metro
dia-metroTipo
Anno costr.
acqua
26
dia-metro
Anno costr.
acquagas
acqua Rete distr. gas
29
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
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.
Limiti e prospettive (seguito)
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
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
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
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
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
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
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
34
Session I – Interoperability as a precondition for the realisation of spatial data infrastructures
Spatial data infrastructures and interoperability
Peter Staub
ETH Zürich, Institut für Geodäsie und Photogrammetrie
Gruppe GIS und Fehlertheorie
35
36
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
P. Staub, ETHZ – Spatial data infrastructures and interoperability
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
EU: INSPIRE directiveNGDI Switzerland Interoperability Model transformationWhat is a SDI?
technical infrastructure
guidelines and standards legal fundamentals* pricing strategy
(advanced) training/research
Networke-geo.ch
38
P. Staub, ETHZ – Spatial data infrastructures and interoperability
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.
EU: INSPIRE directiveNGDI Switzerland Interoperability Model transformationWhat is a SDI?
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
EU: INSPIRE directiveNGDI Switzerland Interoperability Model transformationWhat is a SDI?
39
P. Staub, ETHZ – Spatial data infrastructures and interoperability
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.
EU: INSPIRE directiveNGDI Switzerland Interoperability Model transformationWhat is a SDI?
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
EU: INSPIRE directiveNGDI Switzerland Interoperability Model transformationWhat is a SDI?
40
Session I – Interoperability as a precondition for the realisation of spatial data infrastructures
Prerequisites for interoperability
Stefan Henrich
ETH Zürich, Institut für Geodäsie und Photogrammetrie
Gruppe GIS und Fehlertheorie
41
42
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
S. Henrich, ETHZ – Prerequisites for interoperability
Data exchange among GIS (1)
remainingland cover waterbodies
GIS A
3
forest grassland agriculture waterbodiesGIS B
Data exchange among GIS (2)
remainingdata waterbodies
GIS A
Land Cover
forest grassland agriculture waterbodiesGIS B
44
S. Henrich, ETHZ – Prerequisites for interoperability
• every GIS has an export function to create ASCII (nowadays XML) data• every GIS can import the data that was exported beforehand
Data exchange among GIS (3)
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)
Data exchange among GIS (4)
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
S. Henrich, ETHZ – Prerequisites for interoperability
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
S. Henrich, ETHZ – Prerequisites for interoperability
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
S. Henrich, ETHZ – Prerequisites for interoperability
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
S. Henrich, ETHZ – Prerequisites for interoperability
Example Step 1
• Description of the data in prose – Topic: Swiss Cadastral Register, land coverp g ,– Description already given in Swiss law
…
49
S. Henrich, ETHZ – Prerequisites for interoperability
…
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
S. Henrich, ETHZ – Prerequisites for interoperability
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
S. Henrich, ETHZ – Prerequisites for interoperability
Example Step 3 (continued)
• 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 Step 3 (continued)
Example from the Swiss Government
Model of the Swiss Federal Survey
52
S. Henrich, ETHZ – Prerequisites for interoperability
• Benefit of a CSL (among others): Domain of attributes– Base types
Example Step 3 (continued)
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
Example Step 3 (continued)
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
S. Henrich, ETHZ – Prerequisites for interoperability
• 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
S. Henrich, ETHZ – Prerequisites for interoperability
• 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
S. Henrich, ETHZ – Prerequisites for interoperability
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
Session I – Interoperability as a precondition for the realisation of spatial data infrastructures
Semantic interoperability for INSPIRE: the Swiss-German solution – research project “Model-Driven WFS”
Peter Staub
ETH Zürich, Institut für Geodäsie und Photogrammetrie
Gruppe GIS und Fehlertheorie
57
58
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
P. Staub, ETHZ – Semantic interoperability for INSPIRE: the Swiss-German approach – research project „Model-Driven WFS“
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
P. Staub, ETHZ – Semantic interoperability for INSPIRE: the Swiss-German approach – research project „Model-Driven WFS“
Problem
Germany:AFIS-ATKIS-ALKISEU: INSPIRE
Data Specifications
Suisse:GG25, Vector25
Case study, INSPIRE Problem/solution Formal language WFS Extension Live demo
• Data model EuroSpec FC(Administrative Boundaries)
Problem
( )
Case study, INSPIRE Problem/solution Formal language WFS Extension Live demo
61
P. Staub, ETHZ – Semantic interoperability for INSPIRE: the Swiss-German approach – research project „Model-Driven WFS“
Problem
• Data model AAA (Administrative Gebietseinheiten und Kataloge)
Case study, INSPIRE Problem/solution Formal language WFS Extension Live demo
Problem
• Data model GG25 (Gemeidegrenzen)
Case study, INSPIRE Problem/solution Formal language WFS Extension Live demo
62
P. Staub, ETHZ – Semantic interoperability for INSPIRE: the Swiss-German approach – research project „Model-Driven WFS“
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
Case study, INSPIRE Problem/solution Formal language WFS Extension Live demo
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
Case study, INSPIRE Problem/solution Formal language WFS Extension Live demo
63
P. Staub, ETHZ – Semantic interoperability for INSPIRE: the Swiss-German approach – research project „Model-Driven WFS“
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
Case study, INSPIRE Problem/solution Formal language WFS Extension Live demo
64
P. Staub, ETHZ – Semantic interoperability for INSPIRE: the Swiss-German approach – research project „Model-Driven WFS“
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
Case study, INSPIRE Problem/solution Formal language WFS Extension Live demo
65
P. Staub, ETHZ – Semantic interoperability for INSPIRE: the Swiss-German approach – research project „Model-Driven WFS“
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
Case study, INSPIRE Problem/solution Formal language WFS Extension Live demo
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
Case study, INSPIRE Problem/solution Formal language WFS Extension Live demo
<<metaclass>>AssignmentDefinition
<<eAttribute>> ownedTargetElement : ValueSpecification<<eAttribute>> ownedExpression : ValueSpecification
jointType : JoinType
<<enumeration>>JoinType
equijoinleftjoin
rightjoin
<<metaclass>>VirtualAssociation
{ isDerived = true }
joinCriteria : Expression
66
P. Staub, ETHZ – Semantic interoperability for INSPIRE: the Swiss-German approach – research project „Model-Driven WFS“
UMLT Example Source and target datamodels
Case study, INSPIRE Problem/solution Formal language WFS Extension Live demo
UMLT ExampleTransformation model
Case study, INSPIRE Problem/solution Formal language WFS Extension Live demo
67
P. Staub, ETHZ – Semantic interoperability for INSPIRE: the Swiss-German approach – research project „Model-Driven WFS“
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;
Case study, INSPIRE Problem/solution Formal language WFS Extension Live demo
./.
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.
Case study, INSPIRE Problem/solution Formal language WFS Extension Live demo
68
P. Staub, ETHZ – Semantic interoperability for INSPIRE: the Swiss-German approach – research project „Model-Driven WFS“
UMLT ExampleXMI
Case study, INSPIRE Problem/solution Formal language WFS Extension Live demo
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
Case study, INSPIRE Problem/solution Formal language WFS Extension Live demo
69
P. Staub, ETHZ – Semantic interoperability for INSPIRE: the Swiss-German approach – research project „Model-Driven WFS“
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]
Case study, INSPIRE Problem/solution Formal language WFS Extension Live demo
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
Case study, INSPIRE Problem/solution Formal language WFS Extension Live demo
70
P. Staub, ETHZ – Semantic interoperability for INSPIRE: the Swiss-German approach – research project „Model-Driven WFS“
mdWFS: Demo
„INSPIRE case“
Case study, INSPIRE Problem/solution Formal language WFS Extension Live demo
71
P. Staub, ETHZ – Semantic interoperability for INSPIRE: the Swiss-German approach – research project „Model-Driven WFS“
Case study, INSPIRE Problem/solution Formal language WFS Extension Live demo
1) deegree WFS web interface
Case study, INSPIRE Problem/solution Formal language WFS Extension Live demo
2) WFS feature-types (I), pre-transformation
72
P. Staub, ETHZ – Semantic interoperability for INSPIRE: the Swiss-German approach – research project „Model-Driven WFS“
Case study, INSPIRE Problem/solution Formal language WFS Extension Live demo
3) Generic OGC web service client
Case study, INSPIRE Problem/solution Formal language WFS Extension Live demo
4) WFS GetCapabilities
73
P. Staub, ETHZ – Semantic interoperability for INSPIRE: the Swiss-German approach – research project „Model-Driven WFS“
Case study, INSPIRE Problem/solution Formal language WFS Extension Live demo
5) mdWFS GetCapabilities
Case study, INSPIRE Problem/solution Formal language WFS Extension Live demo
6) mdWFS DoTransform
74
P. Staub, ETHZ – Semantic interoperability for INSPIRE: the Swiss-German approach – research project „Model-Driven WFS“
Case study, INSPIRE Problem/solution Formal language WFS Extension Live demo
7) WFS feature-types (II), post-transformation
Case study, INSPIRE Problem/solution Formal language WFS Extension Live demo
8) WFS GetFeature
75
P. Staub, ETHZ – Semantic interoperability for INSPIRE: the Swiss-German approach – research project „Model-Driven WFS“
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
78
Ontologies evolutionfrom social sciences needs to interop opportunities
Comitato scientifico italo-svizzero per la geoinformazioneLes Marécottes - June 16th 2008
eduardo.camacho-huebner@epfl.ch
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...
E. Camacha-Huebner, EPFL - Ontologies evolution: from social sciences' needs to interop opportunities
80
Information structuration
Geo-historical database
Elementary information: entities, properties and relationships
Explicit kernel (links between concepts and classes)
E. Camacha-Huebner, EPFL - Ontologies evolution: from social sciences' needs to interop opportunities
81
1726 - 1728
1896 - 1911
2006
Information structuration
Ontology
Morphological and historical concepts
Semantic relationships
E. Camacha-Huebner, EPFL - Ontologies evolution: from social sciences' needs to interop opportunities
82
E. Camacha-Huebner, EPFL - Ontologies evolution: from social sciences' needs to interop opportunities
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
E. Camacha-Huebner, EPFL - Ontologies evolution: from social sciences' needs to interop opportunities
84
Polysemy
Stability of definitions
Synonymy and homonymy
disambiguation (concepts)
points of view (conceptualization and arrangements)
declarative sematics (Tarski)
ontologies alignement
E. Camacha-Huebner, EPFL - Ontologies evolution: from social sciences' needs to interop opportunities
85
E. Camacha-Huebner, EPFL - Ontologies evolution: from social sciences' needs to interop opportunities
86
Historical evolution
Historical stability: intervals of validity
Evolution of signification
historical context reduction: epoch-based ontologies
categorization of meta-processes
E. Camacha-Huebner, EPFL - Ontologies evolution: from social sciences' needs to interop opportunities
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
E. Camacha-Huebner, EPFL - Ontologies evolution: from social sciences' needs to interop opportunities
88
Session II – Other aspects of interoperability
Institute of Earth Science: current and future activities at the geomatics division
Dr. Massimiliano Cannata
SUPSI Lugano, Istituto Scienze della Terra
89
90
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
M. Cannata, SUPSI – Institute of Earth Science: current and future activities at the geomatics division
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
M. Cannata, SUPSI – Institute of Earth Science: current and future activities at the geomatics division
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
M. Cannata, SUPSI – Institute of Earth Science: current and future activities at the geomatics division
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
M. Cannata, SUPSI – Institute of Earth Science: current and future activities at the geomatics division
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
M. Cannata, SUPSI – Institute of Earth Science: current and future activities at the geomatics division
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
M. Cannata, SUPSI – Institute of Earth Science: current and future activities at the geomatics division
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
M. Cannata, SUPSI – Institute of Earth Science: current and future activities at the geomatics division
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
M. Cannata, SUPSI – Institute of Earth Science: current and future activities at the geomatics division
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
M. Cannata, SUPSI – Institute of Earth Science: current and future activities at the geomatics division
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
M. Cannata, SUPSI – Institute of Earth Science: current and future activities at the geomatics division
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
M. Cannata, SUPSI – Institute of Earth Science: current and future activities at the geomatics division
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
M. Cannata, SUPSI – Institute of Earth Science: current and future activities at the geomatics division
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
M. Cannata, SUPSI – Institute of Earth Science: current and future activities at the geomatics division
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
M. Cannata, SUPSI – Institute of Earth Science: current and future activities at the geomatics division
Expected direct damages for low probability events
(€ / 750 )years)
Expected direct damages for low probability events
(€ / year)
105
M. Cannata, SUPSI – Institute of Earth Science: current and future activities at the geomatics division
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
M. Cannata, SUPSI – Institute of Earth Science: current and future activities at the geomatics division
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
M. Cannata, SUPSI – Institute of Earth Science: current and future activities at the geomatics division
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
Session II – Other aspects of interoperability
Sensor observation service (SOS): insights and implementations
Milan Antonovic
SUPSI Lugano, Istituto Scienze della Terra
109
110
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
M. Antonovic, SUPSI – Sensor observation service (SOS): insights and implementations
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
M. Antonovic, SUPSI – Sensor observation service (SOS): insights and implementations
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
M. Antonovic, SUPSI – Sensor observation service (SOS): insights and implementations
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
M. Antonovic, SUPSI – Sensor observation service (SOS): insights and implementations
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
M. Antonovic, SUPSI – Sensor observation service (SOS): insights and implementations
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
M. Antonovic, SUPSI – Sensor observation service (SOS): insights and implementations
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
M. Antonovic, SUPSI – Sensor observation service (SOS): insights and implementations
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
M. Antonovic, SUPSI – Sensor observation service (SOS): insights and implementations
SOSSensor Data Consumer
SOSSensor Data Consumer
119
M. Antonovic, SUPSI – Sensor observation service (SOS): insights and implementations
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
M. Antonovic, SUPSI – Sensor observation service (SOS): insights and implementations
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
M. Antonovic, SUPSI – Sensor observation service (SOS): insights and implementations
SOSDeveloping @ SUPSI - IST
http://52north.org
SOSDeveloping @ SUPSI - IST
ER - SOS
122
M. Antonovic, SUPSI – Sensor observation service (SOS): insights and implementations
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
124
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
126
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
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”
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
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”
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
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”
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
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”
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
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”
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
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”
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
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”
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
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”
Valutazione performance
INSPIRE - Draft Implementing Rules for Discovery and View Services (IR1)
17-12-2007
Valutazione performance
Come effettuare effettivamente i test...- PerformancePerformance
- quanti layer?- Availability
- ok- Capacity
- quanti layer?- intervallo di tempo
135
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”
Valutazione performance
Riferimeto test: documento di INSPIRE- software utilizzato per simulazione traffico:software utilizzato per simulazione traffico:
Apache JMeter
http://jakarta.apache.org/jmeter/
136
Session III – Mobile GIS and infrastructure
WebGIS & context aware mobile GIS
Prof. Dr. Maria Brovelli
Politecnico di Milano, Polo Regionale di Como
137
138
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
M. Brovelli, POLIMI – WebGIS & context aware mobile GIS
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
M. Brovelli, POLIMI – WebGIS & context aware mobile GIS
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
M. Brovelli, POLIMI – WebGIS & context aware mobile GIS
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
M. Brovelli, POLIMI – WebGIS & context aware mobile GIS
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
M. Brovelli, POLIMI – WebGIS & context aware mobile GIS
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
M. Brovelli, POLIMI – WebGIS & context aware mobile GIS
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
146
Session III – Mobile GIS and infrastructure
slaxGIS – a GIS-oriented live USB system
Eugenio Realini
Politecnico di Milano, Polo Regionale di Como
147
148
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
E. Realini, POLIMI – slaxGIS: a GIS-oriented live USB system
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
E. Realini, POLIMI – slaxGIS: a GIS-oriented live USB system
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
E. Realini, POLIMI – slaxGIS: a GIS-oriented live USB system
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
E. Realini, POLIMI – slaxGIS: a GIS-oriented live USB system
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
E. Realini, POLIMI – slaxGIS: a GIS-oriented live USB system
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
E. Realini, POLIMI – slaxGIS: a GIS-oriented live USB system
slaxGIS uDig
Free and Open source GIS
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)
Free and Open source GIS
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
E. Realini, POLIMI – slaxGIS: a GIS-oriented live USB system
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
EPF Lausanne, School of Architecture, Civil and Environmental Engineering
Laboratoire de systèmes d’information géographique
157
158
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
francois.golay@epfl.ch
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
F. Golay, EPFL – Update on LaSIG‘s research activities. Some more semantics into the 3rd D: some insights and questions
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
F. Golay, EPFL – Update on LaSIG‘s research activities. Some more semantics into the 3rd D: some insights and questions
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
F. Golay, EPFL – Update on LaSIG‘s research activities. Some more semantics into the 3rd D: some insights and questions
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
F. Golay, EPFL – Update on LaSIG‘s research activities. Some more semantics into the 3rd D: some insights and questions
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
F. Golay, EPFL – Update on LaSIG‘s research activities. Some more semantics into the 3rd D: some insights and questions
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
Session IV – Added value of the 3rd dimension through enriched semantics
Matching 3D city models and urban indicators to users’ needs
Cláudio Carneiro
EPF Lausanne, School of Architecture, Civil and Environmental Engineering
Laboratoire de systèmes d’information géographique
165
166
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)Claudio.Carneiro@epfl.ch ; Francois.Golay@epfl.ch
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
C. Carneiro, EPFL – Matching 3D city models and urban indicators to users‘ needs
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 !...
Modèles urbains et indicateurs 3D: Introduction
… mais que peut-on bien en faire ?!
168
C. Carneiro, EPFL – Matching 3D city models and urban indicators to users‘ needs
On peut bénéficier d’un modèle urbain 3Dsans même passer par la représentation 3D !
Exemple:
Modèles urbains et indicateurs 3D: Introduction
Evaluation des immissions du bruit routier –
le modèle de simulation pourrait utiliser les points LIDAR bruts…
Modèles urbains et indicateurs 3D: Introduction
Résultat de la modélisation satisfaisant…
… mais pourquoi pas une interface
exploratoire 3D !?
169
C. Carneiro, EPFL – Matching 3D city models and urban indicators to users‘ needs
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
C. Carneiro, EPFL – Matching 3D city models and urban indicators to users‘ needs
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
C. Carneiro, EPFL – Matching 3D city models and urban indicators to users‘ needs
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
C. Carneiro, EPFL – Matching 3D city models and urban indicators to users‘ needs
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
C. Carneiro, EPFL – Matching 3D city models and urban indicators to users‘ needs
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) …
Modèles urbains et indicateurs 3D: Reconstruction de modèles 3D urbains
+ 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
Modèles urbains et indicateurs 3D: Reconstruction de modèles 3D urbains
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
C. Carneiro, EPFL – Matching 3D city models and urban indicators to users‘ needs
Modèle 3D Urbain Numérique d’Haute Précision
Modèles urbains et indicateurs 3D: Reconstruction de modèles 3D urbains
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
C. Carneiro, EPFL – Matching 3D city models and urban indicators to users‘ needs
Modèles urbains et indicateurs 3D: Quelques exemples d’indicateurs urbains
Cartes de visibilité (ISOVISTES)
Cartes de visibilité (ISOVISTES)
Modèles urbains et indicateurs 3D: Quelques exemples d’indicateurs urbains
176
C. Carneiro, EPFL – Matching 3D city models and urban indicators to users‘ needs
Cartes de visibilité (ISOVISTES)
Modèles urbains et indicateurs 3D: Quelques exemples d’indicateurs urbains
Cartes de visibilité (ISOVISTES)
Modèles urbains et indicateurs 3D: Quelques exemples d’indicateurs urbains
177
C. Carneiro, EPFL – Matching 3D city models and urban indicators to users‘ needs
Localisation de nouveaux bâtiments: visualisation 2D(en collaboration avec Prof. Corinne Plazanet, EPFL)
Modèles urbains et indicateurs 3D: Quelques exemples d’indicateurs urbains
Exposition solaire sur les façades des bâtiments(en collaboration avec Eugenio Morello, Senseable City Laboratory, MA, USA)
Modèles urbains et indicateurs 3D: Quelques exemples d’indicateurs urbains
178
C. Carneiro, EPFL – Matching 3D city models and urban indicators to users‘ needs
Modèles urbains et indicateurs 3D: Quelques exemples d’indicateurs urbains BlackBox
Radiation solaire par bâtiment (W/m2): visualisation 3D
Modèles urbains et indicateurs 3D: Quelques exemples d’indicateurs urbains
179
C. Carneiro, EPFL – Matching 3D city models and urban indicators to users‘ needs
Radiation moyenne par façade (W/m2): visualisation 2D
Modèles urbains et indicateurs 3D: Quelques exemples d’indicateurs urbains
Technique appliquée pour la mise en
Modèles urbains et indicateurs 3D: Quelques exemples d’indicateurs urbains
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
C. Carneiro, EPFL – Matching 3D city models and urban indicators to users‘ needs
Modèles urbains et indicateurs 3D: Quelques exemples d’indicateurs urbains
Calcul des pentes
des toits…
Modèles urbains et indicateurs 3D: Quelques exemples d’indicateurs urbains
Calcul del’orientationdes toits…
181
C. Carneiro, EPFL – Matching 3D city models and urban indicators to users‘ needs
Radiation sur les toits (W/m2): visualisation 2.5D
Modèles urbains et indicateurs 3D: Quelques exemples d’indicateurs urbains
Sélection des toits mieux adaptés à recevoir des panneaux solaires(projet en développement, en collaboration avec Gilles Desthieux, LEEA, Geneva)
Modèles urbains et indicateurs 3D: Quelques exemples d’indicateurs urbains
Segmentation des toits (surface)g ( )
Segmentation des toits (pente)
Segmentation des toits (orientation)
Segmentation des toits (radiation)
182
C. Carneiro, EPFL – Matching 3D city models and urban indicators to users‘ needs
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)
Modèles urbains et indicateurs 3D: Quelques exemples d’indicateurs urbains
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
184
Session IV – Added value of the 3rd dimension through enriched semantics
Landscape characterization using wavelet detail coefficients
Michaël Kalbermatten
EPF Lausanne, School of Architecture, Civil and Environmental Engineering
Laboratoire de systèmes d’information géographique
185
186
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
michael.kalbermatten@epfl.ch
High resolution DEM generalization
Contents
High resolution DEM generalization
Wavelets, why? how? results?
Low pass coefficients
High pass coefficients – Inverse Wavelet transform
Landslide case study
Further work
187
M. Kalbermatten, EPFL – Landscape characterization using wavelet detail coefficients
High resolution DEM generalization
High resolution DEM generalization
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
High resolution DEM generalization
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
M. Kalbermatten, EPFL – Landscape characterization using wavelet detail coefficients
High resolution DEM generalization
Wavelet theory (2) Wavelets are local spectral analysis tools with compact support.
Wavelet:
High resolution DEM generalization
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
M. Kalbermatten, EPFL – Landscape characterization using wavelet detail coefficients
High resolution DEM generalization
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).
High resolution DEM generalization
Wavelet theory (5)
190
M. Kalbermatten, EPFL – Landscape characterization using wavelet detail coefficients
High resolution DEM generalization
Wavelets results – Second decomposition
High resolution DEM generalization
Low pass coefficients - Results
2nd decomposition(resolution: 4m)
191
M. Kalbermatten, EPFL – Landscape characterization using wavelet detail coefficients
High resolution DEM generalization
Low pass coefficients - Results
3rd decomposition(resolution: 8m)
High resolution DEM generalization
Low pass coefficients - Results
4th decomposition(resolution: 16m)
192
M. Kalbermatten, EPFL – Landscape characterization using wavelet detail coefficients
High resolution DEM generalization
Low pass coefficients - Results
5th decomposition(resolution: 32m)
High resolution DEM generalization
Low pass coefficients - Results
6th decomposition(resolution: 64m)
193
M. Kalbermatten, EPFL – Landscape characterization using wavelet detail coefficients
High resolution DEM generalization
Low pass coefficients - Results
7th decomposition(resolution: 128m)
High resolution DEM generalization
Elevation and slope analysis – Scatterogram
194
M. Kalbermatten, EPFL – Landscape characterization using wavelet detail coefficients
High resolution DEM generalization
High pass coefficients (1)
InverseWT
High resolution DEM generalization
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
M. Kalbermatten, EPFL – Landscape characterization using wavelet detail coefficients
High resolution DEM generalization
High pass coefficients - Results
2nd recomposition(coefficients 1 to 2)
High resolution DEM generalization
High pass coefficients - Results
3rd recomposition(coefficients 1 to 3)
196
M. Kalbermatten, EPFL – Landscape characterization using wavelet detail coefficients
High resolution DEM generalization
High pass coefficients - Results
4th recomposition(coefficients 1 to 4)
High resolution DEM generalization
High pass coefficients - Results
5th recomposition(coefficients 1 to 5)
197
M. Kalbermatten, EPFL – Landscape characterization using wavelet detail coefficients
High resolution DEM generalization
High pass coefficients - Results
6th recomposition(coefficients 1 to 6)
High resolution DEM generalization
High pass coefficients - Results
7th recomposition(coefficients 1 to 7)
198
M. Kalbermatten, EPFL – Landscape characterization using wavelet detail coefficients
High resolution DEM generalization
Landslide case study – Theoretical analysis
Modelization of a simple virtual landslide.
Filtering with wavelet transform.
Reconstruction of high pass coefficients.
High resolution DEM generalization
Landslide case study – Theoretical analysis - Results
Low pass results
1st decomp.(resolution 2m)
~500m
199
M. Kalbermatten, EPFL – Landscape characterization using wavelet detail coefficients
High resolution DEM generalization
Landslide case study – Theoretical analysis - Results
Low pass results
2nd decomp.(resolution 4m)
~500m
High resolution DEM generalization
Landslide case study – Theoretical analysis - Results
Low pass results
3rd decomp.(resolution 8m)
~500m
200
M. Kalbermatten, EPFL – Landscape characterization using wavelet detail coefficients
High resolution DEM generalization
Landslide case study – Theoretical analysis - Results
Low pass results
4th decomp.(resolution 16m)
~500m
High resolution DEM generalization
Landslide case study – Theoretical analysis - Results
Low pass results
5th decomp.(resolution 32m)
~500m
201
M. Kalbermatten, EPFL – Landscape characterization using wavelet detail coefficients
High resolution DEM generalization
Landslide case study – Theoretical analysis - Results
Low pass results
6th decomp.(resolution 64m)
~500m
High resolution DEM generalization
Landslide case study – Theoretical analysis - Results
Low pass results
7th decomp.(resolution 128m)
~500m
202
M. Kalbermatten, EPFL – Landscape characterization using wavelet detail coefficients
High resolution DEM generalization
Landslide case study – Theoretical analysis - Results
Low pass results
8th decomp.(resolution 256m)
~500m
High resolution DEM generalization
Landslide case study – Theoretical analysis - Results
High pass results
~500m2nd recomposition(coefficients 1 to 2)
203
M. Kalbermatten, EPFL – Landscape characterization using wavelet detail coefficients
High resolution DEM generalization
Landslide case study – Theoretical analysis - Results
High pass results
~500m3rd recomposition(coefficients 1 to 3)
High resolution DEM generalization
Landslide case study – Theoretical analysis - Results
High pass results
~500m4th recomposition(coefficients 1 to 4)
204
M. Kalbermatten, EPFL – Landscape characterization using wavelet detail coefficients
High resolution DEM generalization
Landslide case study – Theoretical analysis - Results
High pass results
~500m5th recomposition(coefficients 1 to 5)
High resolution DEM generalization
Landslide case study – Theoretical analysis - Results
High pass results
~500m6th recomposition(coefficients 1 to 6)
205
M. Kalbermatten, EPFL – Landscape characterization using wavelet detail coefficients
High resolution DEM generalization
Landslide case study – Theoretical analysis - Results
High pass results
~500m7th recomposition(coefficients 1 to 7)
High resolution DEM generalization
Landslide case study – Theoretical analysis - Results
High pass results
~500m8th recomposition(coefficients 1 to 8)
206
M. Kalbermatten, EPFL – Landscape characterization using wavelet detail coefficients
High resolution DEM generalization
Landslide case study – Theoretical analysis - Results
High pass results – Only coefficients from 8th decomposition level
~500m
High resolution DEM generalization
Landslide case study – Applied analysis
Analysis on 1m resolution DEM in Val de Travers – Neuchâtel – CH
Helicopter laserscanning, TIN interpolation
207
M. Kalbermatten, EPFL – Landscape characterization using wavelet detail coefficients
High resolution DEM generalization
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
High resolution DEM generalization
Landslide case study – Applied analysis – Detail coefficients
Level 1 to 2 Level 1 to 3
208
M. Kalbermatten, EPFL – Landscape characterization using wavelet detail coefficients
High resolution DEM generalization
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)
High resolution DEM generalization
Landslide case study – Applied analysis – Detail coefficients
Level 1 to 4 Level 1 to 5
209
M. Kalbermatten, EPFL – Landscape characterization using wavelet detail coefficients
High resolution DEM generalization
Landslide case study – Applied analysis - Comments
In deposit zone: identification of the bigger bulges
In scarp zone:
− Main streams
− Water flow modelof landslide
High resolution DEM generalization
Landslide case study – Applied analysis – Detail coefficients
Level 1 to 6 Level 1 to 7
210
M. Kalbermatten, EPFL – Landscape characterization using wavelet detail coefficients
High resolution DEM generalization
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:
High resolution DEM generalization
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
212
Session IV – Added value of the 3rd dimension through enriched semantics
3D web interfaces to the “Patrouille des Glaciers” race
Jens Ingensand
EPF Lausanne, School of Architecture, Civil and Environmental Engineering
Laboratoire de systèmes d’information géographique
213
214
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
J. Ingensand, EPFL – 3D web interface to the „Patrouille des Glaciers“ race
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
J. Ingensand, EPFL – 3D web interface to the „Patrouille des Glaciers“ race
L‘EPFL à la Patrouille des glaciers
M tt d- Maquette du parcours- Peaux de phoque- Mesures physiologiques- Transfert et stockage des données- Visualisation
- Microstations météorologiques
L‘EPFL à la Patrouille des glaciers
M tt d- Maquette du parcours- Peaux de phoque- Mesures physiologiques- Transfert et stockage des données- Visualisation
- Microstations météorologiques
217
J. Ingensand, EPFL – 3D web interface to the „Patrouille des Glaciers“ race
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.
Mesures physiologiques & géographiques
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
J. Ingensand, EPFL – 3D web interface to the „Patrouille des Glaciers“ race
Mesures physiologiques & géographiques
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
J. Ingensand, EPFL – 3D web interface to the „Patrouille des Glaciers“ race
Transfert et stockage des données
Transfert et stockage des données
Balise 1
EPFL
1 fois / min
Serveur- reception des
données (Java)- stockage dans BD(Postgresql/PostGIS)
Balise 2 1 fois / min
220
J. Ingensand, EPFL – 3D web interface to the „Patrouille des Glaciers“ race
Visualisation en temps réel
stand EPFL à Verbier- stand EPFL à Verbier- visualisation Google Earth - visualisation sur maquette physique- visualisation données physiologiques
VerbierInternet
EPFL
- Visualisaition site web polypdg.epfl.ch
VerbierEPFL
Visualisation en temps réel
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
J. Ingensand, EPFL – 3D web interface to the „Patrouille des Glaciers“ race
Visualisation en temps réel
visualisation sur maquette physiquevisualisation sur maquette physique
Projection avec beamer
Visualisation en temps réel
visualisation sur maquette physiquevisualisation sur maquette physique
Projection avec beamer
222
J. Ingensand, EPFL – 3D web interface to the „Patrouille des Glaciers“ race
Visualisation en temps réel
visualisation site web polypdg epfl chvisualisation site web polypdg.epfl.ch
Visualisation en temps réel
visualisation données physiologiquesvisualisation données physiologiques
223
J. Ingensand, EPFL – 3D web interface to the „Patrouille des Glaciers“ race
http://polypdg.epfl.ch
224
225
ISBN 978-3-906467-77-1 IGP Bericht Nr. 305
top related