Progettazione e sviluppo di un Web Feature Service per dati geospaziali

Università degli Studi di Padova

Facoltà di Ingegneria

Corso di Laurea Specialistica in Ingegneria Informatica

tesi di laurea

Progettazione e sviluppo di un Web Feature Service per dati geospaziali

in formato CityGML basato su strumenti opensource.

Relatore: prof. Massimo Rumor

Laureando: Daniele Toniolo

18 aprile 2011

anno accademico 2010/2011

III

Alla mia famiglia

in particolare ai miei genitori

per avermi sempre sostenuto.

Sommario

L’OGC (Open Geospatial Consortium) ha prodotto due specifiche per la strut- turazione dei dati urbani in tre dimensioni, denominate CityGML e KML ed ha anche standardizzato, in una architettura SOA, un insieme di servizi dedicati ai dati spaziali in due dimensioni.

Sono in discussione, ma non sono state ancora emanate specifiche per gli stessi

servizi per i dati tridimensionali. Il presente lavoro riguarda proprio lo sviluppo

di un servizio web, per l’accesso a feature tridimensionali progettato in analo-

gia all’omologo servizio WFS standardizzato per i dati bidimensionali, con la

possibilità di personalizzare la vestizione grafica degli oggetti 3D per mezzo

dello standard SLD. Il servizio è stato sviluppato come estensione del server

geospaziale FOSS Geoserver.

Indice

1 Premessa 1

2 Obiettivi 3

3 Standard OGC 5

3.1 OpenGIS

Web Feature Service . . . . 5

3.1.1 Funzioni ed operazioni principali . . . . 5

3.1.2 Namespaces . . . . 7

3.1.3 Operazione DescribeFeatureType . . . . 8

3.1.4 Operazione GetFeature . . . . 8

3.1.5 Operazione GetCapabilities . . . . 11

3.2 OpenGIS

Filter Encoding . . . . 16

3.2.1 Elementi Filter Encoding . . . . 16

3.3 OpenGIS

Styled Layer Descriptor . . . . 19

3.3.1 Elementi SLD . . . . 20

3.4 OpenGIS

CityGML . . . . 25

3.4.1 Caratteristiche generali . . . . 26

3.4.2 modellazione geometrica e semantica . . . . 28

4 Tecnologie utilizzate 29 4.1 PostgreSQL/PostGIS . . . . 29

4.2 Geoserver . . . . 31

4.2.1 Struttura catalogo . . . . 32

4.2.2 Servizi e dati supportati . . . . 34

5 Servizio WFS per CityGML 37 5.1 Stato dell’arte . . . . 37

5.2 Progettazione e Sviluppo . . . . 39

5.2.1 Architettura . . . . 39

5.2.2 Interfaccia web . . . . 42

5.2.3 Implementazione . . . . 49

6.1 Esempi di richieste WFS 3D . . . . 55

7 Conclusioni 63 7.1 Sviluppi futuri . . . . 63

A Schemi XML 65 A.1 Schema Web Feature Service . . . . 65

A.1.1 DescribeFeatureType schema . . . . 65

A.1.2 GetFeaure schema request . . . . 65

A.1.3 GetFeature schema response . . . . 67

A.1.4 GetCapabilities schema Response . . . . 67

A.2 Esempio style.sld . . . . 68

Bibliografia 72

Capitolo 1 Premessa

L’utilizzo di modelli tridimensionali è in aumento, come si rileva dallo sviluppo dei ben noti applicativi Google Earth e Virtual Earth.

L’OGC (Open Geospatial Consortium) ha prodotto due specifiche per la strutturazione dei dati urbani in tre dimensioni, denominate CityGML e KML e questo ha stimolato la realizzazione di strumenti ed applicazioni desktop per visualizzare ed analizzare dati 3D.

I due modelli standard sono definiti entrambi in formato XML. KML è un modello puramente geometrico, CityGML invece comprende oltre alla geome- tria anche la topologia, le appearance e l’informazione semantica associata agli oggetti 3D.

Sempre OGC, a fronte dello sviluppo dei sistemi GIS e della necessità di aumentare il livello di interoperabilità, ha standardizzato, in una architettura SOA, un insieme di servizi dedicati ai dati spaziali in due dimensioni.

In questo contesto le infrastrutture di dati territoriali forniscono una struttura appropriata per un accesso flessibile alle varie sorgenti di dati distribuite. L’uti- lizzo dei servizi standard OGC comporta due importanti vantaggi per gli utenti, del dato geografico: l’inutilità di duplicazione dei dati in locale e la certezza di consultare/utilizzare una versione certificata dei dati richiesti in quanto il dato viene distribuito direttamente da chi lo produce o ne certifica l’attendibilità.

Sono in discussione, ma non sono state ancora emanate specifiche per gli stessi servizi per i dati tridimensionali.

Il presente lavoro riguarda lo sviluppo di un servizio web dedicato ai dati

tridimensionali urbani.

Capitolo 2 Obiettivi

Nell’ambito di questa tesi è descritto il lavoro di progettazione e sviluppo di un Web Service per l’acceso ai dati vettoriali tridimensionali gestiti in un geoDBMS in analogia a WFS, standard OGC per i dati bidimensionali.

L’Interfaccia Standard OpenGIS Web Feature Service (WFS) permette la richi- esta e l’importazione da parte di un client di oggetti geografici attraverso il Web, usando chiamate indipendenti dalla piattaforma. La codifica standard è il GML, basata su XML, ma anche altri formati possono essere usati per il trasporto delle informazioni.

Numerosi server geospaziali, come ad esempio Geoserver e Mapserver, im- plementano la componente WFS permettendo una comoda interfaccia per lo scambio di dati. Attualmente tuttavia l’implementazione è relativa alla sola parte bidimensionale.

Il servizio WFS 3D realizzato si occupa di rispondere alle richieste effet- tuate secondo lo standard WFS e di:

• fornire le geometrie richieste nel formato CityGML;

• tematizzare dinamicamente sulla base di parametri applicati in input;

Questo progetto utilizza le strutture dati e gli strumenti predisposti nell’am-

bito della tesi “Progettazione e sviluppo di un toolkit per la gestione di dati

spaziali 3D nei formati standard OGC CityGML e KML per il geodatabase

opensource PostGIS.” [1].

Capitolo 3

Standard OGC

L’Open Geospatial Consortium è un consorzio internazionale no-profit costi- tuito da aziende private, agenzie governative ed università che si prefigge di sviluppare delle regole standard per i servizi geospaziali.

Questi sono classificabili come sistemi software che scambiano dati sul proto- collo HTTP. L’interazione tra i servizi e le applicazioni avviene mediante l’invio di messaggi XML. Il sistema di comunicazione garantisce l’interoperabilità es- sendo indipendente dalla piattaforma hardware, dal sistema operativo e dal for- mato originario dei dati: qualsiasi software client e server possono comunicare tra di loro purché implementino in modo corretto gli standard. L’interscambio di dati geo-spaziali avviene tra diversi elaboratori facenti parte della stessa rete o facenti parte di reti diverse comunicanti tra loro ( World Wide Web). Tra gli standard più importanti si citano:

• Web Feature Service 3.1;

• Filter Encoding 3.2;

• Styled Layer Descriptor 3.3;

• CityGML 3.4.

3.1 OpenGIS ^® Web Feature Service

3.1.1 Funzioni ed operazioni principali

L’Interfaccia Standard OpenGIS Web Feature Service (WFS) permette la richi- esta e l’importazione da parte di un client di oggetti geografici attraverso il Web, usando chiamate indipendenti dalla piattaforma.

Il protocollo WFS supporta le operazioni di INSERT, UPDATE, LOCK, QUERY

e DISCOVERY su feature geografiche usando HTTP come piattaforma di elab- orazione distribuita. In termini generali il protocollo deve essere eseguito in or- dine ai processi di richiesta WFS. Le elaborazioni dovrebbero procedere come segue:

1. Un’applicazione client dovrebbe richiedere un documento capabilites dal WFS. Tale documento contiene una descrizione di tutte le operazioni che il WFS supporta ad una lista di feature disponibili;

2. (Opzionale) Un’applicazione client effettua una richiesta al web feature service per la definizione di una o più tipi di elementi e feature;

3. Basandosi sulla definizione dei tipi di feature, l’applicazione client genera una richiesta;

4. La richiesta viene spedita al web server;

5. Il WFS è invocato per leggere e servire la richiesta inviata;

6. Quando il WFS ha completato di processare la richiesta, esso genererà una risposta la quale verrà restituita al client. Se nell’evento vi è accorso un errore, la risposta dovrà indicare tale errore.

Per supportare i processi di transazioni e interrogazioni, sono definite le seguenti operazioni:

GetCapabilities

Un web feature service può essere in grado di descrivere le proprie capa- bilities. Più in dettaglio dovrebbe indicare quali tipi di feature può servire e le operazioni supportate per ogni feature.

DescribeFeatureType

Un web feature service può essere in grado, su richiesta, di descrivere la struttura di ogni tipo di feature che può servire.

GetFeature

Un web feature service può essere in grado di rispondere ad una richies- ta, reperendo l’istanza della feature. Inoltre, il client dovrebbe essere in grado di specificare quale proprietà delle feature estrarre, e di vincolare tramite query.

GetGMLObject

3.1 OpenGIS

Web Feature Service 7 Un web feature service può essere in grado di servire una richiesta, e reperire le istanze degli elementi tramite l’attraversamento di XLink che riferiscono al loro XML ID.

Transaction

Un web feature service può essere in grado di servire una richiesta di transazione. Una richiesta di transazione composta di operazioni che modificano le feature, come operazioni per creare, aggiornare e eliminare feature geografiche.

LockFeature

Un web feature service può essere in grado di servire una richiesta di lock su una o più istanze di una feature type per la durata di una transizione.

Questo assicura che la serializzazione delle transizioni è supportata.

Basandosi sulle operazioni descritte in precedenza tre classi di web feature service possono essere descritte:

Basic WFS

Un Basic WFS deve implementare le operazioni GetCapabilites, DescribeFea- tureType e GetFeature. Questo si può considerare un web feature service di sola lettura.

XLink WFS

Un XLink WFS deve supportare tutte le operazioni di un basic web fea- ture services ed in più deve implementare l’operazione GetGMLObject per XLink locali o remoti. Inoltre offre le opzioni per l’operazione Get- GMLObject per essere performante durante le operazioni GetFeature.

Transaction WFS

Un Transaction WFS deve supportare tutte le operazioni di un Basic web feature services inoltre deve implementare le operazioni Transac- tion. Opzionalmente un Trasaction WFS può implementare le operazioni GetGMLObject e LockFeature.

3.1.2 Namespaces

I namespaces sono utilizzati per discriminare i dizionari XML gli uni dagli altri.

Per il WFS ci sono tre definizioni di namespace che seguono la normativa, ossia:

• (http://www.opengeospatial.net/wfs) - per il dizionario dell’interfaccia WFS

• (http://www.opengeospatial.net/gml) - Per il dizionario GML

• (http://www.opengeospatial.net/ogc) - Per il dizionario dei filtri OGC Una implementazione WFS potrebbe far uso di uno o più schemi di GML e questi schemi utilizzeranno, a loro volta, uno o più namespaces.

3.1.3 Operazione DescribeFeatureType

La funzione dell’operazione DescribeFeatureType è di generare uno schema di descrizione di una feature type richiesta ad un WFS. Lo schema di descrizione definisce le codifiche in ingresso delle feature (attraverso Insert e richieste di Update) e come le istanze delle feature verranno generate in uscita (in risposta a GetFeature ed a richieste GetGmlObject). L’unica risposta obbligatoria ad una richiesta DescribeFeatureType è uno GML3 application schema definito utilizzando XML Schema.

Richiesta

Un elemento DescribeFeatureType contiene zero o più elementi TypeName che codificano il nome di una feature type che devono essere descritte. Se il con- tenuto dell’elemento DescribeFeatureType è vuoto, allora questo verrà interpre- tato come richiesta di una descrizione di tutti i tipi di elementi che un WFS può servire. Il frammento di schema XML che definisce la codifica di una richiesta DescribeFeatureType è inA.1.1.

Risposta

In risposta ad una richiesta DescribeFeatureType, in cui il valore dell’attributo outputFormat è stato impostato a text/xml;subtype=gml/3.1.1, il WFS deve es- sere in grado di presentare un documento XML Schema valido e definendo lo schema della feature type elencate nella richiesta.

3.1.4 Operazione GetFeature

In GML una feature è rappresentata come un elemento XML. Il nome dell’ele- mento di una feature indica il FeatureType convenzionalmente dato in Upper- CamelCase(Maiuscola), come xmml:BoreHole.

Il contenuto di una feature è un insieme di elementi, che descrivono la fea-

ture come un insieme di proprietà. Il nome di una proprietà indica il tipo

di proprietà, convenzionalmente dato nel LowerCamelCase(minuscola), come

3.1 OpenGIS

Web Feature Service 9 gml:boundedBy o xml:collarLocation.

Il valore di una proprietà è dato in linea con il contenuto dell’elemento, o per riferimento come valore di una risorsa identificata in un link effettuato come un attributo XML dell’elemento proprietà. Se la forma in linea è usata, allora il contenuto può essere un letterale (numero, testo, . . . ), o può essere costruito usando elementi XML, ma nessuna ipotesi può essere fatta circa la struttura del valore di una proprietà.

L’operazione GetFeature consente il recupero di feature da un web feature ser- vice. Una richiesta GetFeature viene elaborata da un WFS e quando il valore dell’attributo outputFormat è impostato a text/GML;subtype=gml/3.1.1, viene restituita al client una istanza del documento GML, contenente l’insieme dei risultati.

Richiesta

La codifica XML di una richiesta GetFeature viene esposta dal frammento di schema XML in A.1.2.

L’elemento <GetFeature> contiene uno o più elementi <query>, ognuno dei quali contiene la descrizione di una interrogazione. I risultati di tutte le query contenute in una richiesta GetFeature sono concatenate per produrre il set di risultati.

Gli attributi opzionali outputFormat specificano il formato della risposta alla richiesta GetFeature. Il valore di deafult è text/xml;subtype=gml/3.1.1 indi- cando che è un documento valido GML3. Per la retrocompatibilità, il valore GML2 o text/xml;subtype=gml/2.1.2 può essere specificato indicando che un documento in formato GML2 può essere generato.

Altri formati di output sono possibili per valori appropriati per l’attributo out- putFormat che sono indicati nel documento GetCapabilities.

Un web feature service può rispondere ad una richiesta GetFeature in due modi. Può o generare un documento di risposta completo o più semplice- mente ritornare un conteggio del numero di feature che una richiesta GetFea- ture dovrebbe ritornare. L’attributo opzionale resultType è usato per controllare come un web feature service risponde ad una richiesta GetFeature. I possibili valori per l’attributi elencati nella Tabella 3.1

L’attributo maxFeature limita il numero massimo di feature che possono es- sere restituite dopo una richiesta getFeature. Di default questo parametro non è settato e quindi vengono restituite tutte le feature senza limitazioni.

Ogni singola query contenuta in una richiesta GetFeature è definita usando

l’elemento <query>. L’elemento <query> definisce quale FeatureType inter-

rogare, quali proprietà reperire e quali vincoli applicare al fine di selezionare il

Valore Descrizione

Results Il valore di default, indica che il WFS

deve generare come risposta l’intero documento

Hits Il valore indica che il WFS ritorna la sola

enumerazione delle feature che dovrebbe restituire

Tabella 3.1: Valori per l’attributo resultType

set delle feature valido.

L’attributo obbligatorio typeName è usato per indicare il nome di una o più istanze di FeatureType o istanze di classi che sono interrogate. Il suo valore è una lista di namespace-qualified, il cui valore deve corrispondere a uno dei FeatureType mostrato nel documento Capabilities del WFS. Indicare più di un typeName indica l’uso di una operazione di join. Tutti i nomi nella lista type- Name devo essere tipi validi che appartengono al contenuto di questa feature query come definito dall’Application Schema GML.

L’attributo opzionale featureVersion su l’elemento <query> è utilizzato per fa- vorire i sistemi che supportano il versioning. L’attributo opzionale srsName di un elemento <query> è usato per specificare uno specifico SRS(Spatial Refer- ence System) supportato dal WFS da utilizzare per ritornare le feature geomet- riche.

Il valore di ogni elemento <wfs:PropertyName> è un namespace-qualified (ad esempio myns:address) il cui valore deve corrispondere ad una delle proprietà della feature pertinente. La feature pertinente è del tipo indicato nell’attributo typeName dell’elemento <Query>. Il nome degli elementi property possono essere scoperti dallo schema della feature type, ottenuto come risultato di una DescribeFeatureType.

La risposta ad un richiesta Getfeature deve essere in accordo alla struttura de- scritta dallo XML schema della FeatureType. Il WFS deve riportare tutte le proprietà obbligatorie di ogni feature, così come ogni proprietà richiesta at- traverso l’elemento <wfs:PropertyName>. Nel caso che un WFS incontri una query che non seleziona tutte le proprietà obbligatorie di una feature, il WFS au- tomaticamente dovrà aumentare la lista delle proprietà per includere tutti i nomi obbligatori. Un client deve essere in grado di trattare una situazione dove riceve più valori di quelli che ha richiesto attraverso l’elemento <wfs:PropertyName>.

L’elemento Filter è usato per definire i filtri sulla query. Possono essere

specificati filtri spaziali e/o non spaziali e vengono descritti in 3.2].

3.1 OpenGIS

Web Feature Service 11 Risposta

Il formato di una risposta ad una richiesta GetFeture è controllata attraverso l’at- tributo outputFormat. Il valore di default dell’attributo outputFormat è text/xml;

subtype=gml/3.1.1. Questo indica che un WFS deve generare un documento GML che risulterà conforme alle OpenGis Geography Markup Language Im- plementation Specification [2], versione 3.1.1, e più specificatamente, l’output deve essere valido con lo schema generato dalla operazione DescribeFeature- Type.

L’elemento radice di una risposta ad una operazione GetFeture deve essere l’elemento <wfs:FeatureCollection> il quale definito attraverso dal frammento di XML schema in A.1.3

Il contenuto dell’elemento <wfs:FeatureCollection> è controllato tramite il val- ore dell’attributo resulType sull’elemento <GetFeture>.

3.1.5 Operazione GetCapabilities

Ogni OGC Web Service (OWS), incluso un Web Feature Service, deve avere la capacità di descrivere le capabilities(capacità), attraverso un servizio di ri- torno di metadati in risposta ad una richiesta GetCapabilities. Specificamente, ogni web feature service deve supportare la forma KVP che codifica la richiesta GetCapabilities su HTTP GET in modo che un client possa sempre conoscere come ottenere un documento capabilities.

Richiesta

L’elemento <GetCapabilities> è usato per richiedere un documento capabilities ad un web feature service. Di seguito viene definito lo schema XML per una richiesta:

< x s d : e l e m e n t name =" G e t C a p a b i l i t i e s " t y p e =" wfs : G e t C a p a b i l i t i e s T y p e " / >

< x s d : c o m p l e x T y p e name =" G e t C a p a b i l i t i e s T y p e " >

< x s d : c o m p l e x C o n t e n t >

< x s d : e x t e n s i o n b a s e =" ows : G e t C a p a b i l i t i e s T y p e " >

< x s d : a t t r i b u t e name =" s e r v i c e " t y p e =" ows :

S e r v i c e T y p e " u s e =" o p t i o n a l " d e f a u l t ="WFS" / >

</ x s d : e x t e n s i o n >

</ x s d : c o m p l e x C o n t e n t >

</ x s d : complexType >

Risposta

L’elemento radice della risposta ad una richiesta <GetCapabilities> è l’ele- mento <WFS_Capabilities> ed è definito dal frammento di schema XML in A.1.4.

Dallo schema si può notare come il documento capabilities è suddiviso in sezioni.

Service Indentification La sezione ServiceIdentification, contiene metadati di base dello specifico server. La sezione ServiceIdentification comprende i paramatri e le parti descritte e specificate nella tabella Tabella 3.2

Sezione ServiceProvider La sezione ServiceProvider, contiene metadati cir- ca l’organizzazione operarativa di questo server. La sezione ServiceProvider comprende i paramatri e le parti descritte e specificate nella tabella Tabella 3.3

Sezione OperationsMetadata La sezione OperationsMetadata contiene i meta- dati relativi alle operazioni fornite ed implementate dal servizio, inclusi gli URL per le varie operazioni supportate. La sezione OperationsMetadata comprende le sottosezioni descritte e specificate nella tabella Tabella 3.4.

Sezione FeatureTypeList La sezione FeatureTypeList definisce le operazioni comuni tra tutti i tipi di feature e la descrizione di ogni feature che il servizio offre. La sezione FeatureTypeList comprende le sottosezioni descritte e spec- ificate nella tabella Tabella 3.5 e Tabella 3.6 .

Sezione ServesGMLObjectType La sezione ServesGMLObjectType contiene una lista di nomi di oggetti di tipo GML che un web feature service, supportan- do l’operazione GetGMLObject, offre.

Sezione SupportGMLObjectTypeList Questa sezione definisce la lista di

oggetti GML che un WFS server sarebbe in grado di elaborare;

3.1 OpenGIS

Web Feature Service 13

Nomi Definizione Tipi di Dati Molteplicità

serviceType usato per le

comunicazioni macchina- macchina

URN

Uno(Obbligatorio)

version Versione del ser-

vice type imple- mentato

String Uno o più (ob-

bligatorio) Uno per ogni versione implementata dal server (non ordinata)

profile Identificatore di

una application profile OWS

String zero o più

(opzionale) title titolo del server LanguageString uno o più (obbliga-

torio) abstract Breve descrizione

di questo server, normalmente disponibile alla visualizzazione

String Zero o pi

(opzionale)

keywords lista non ordinata di una o pi paro- la(e) o frase(i) co- munemente usate o formalizzate per descrivere il server

MD_Keywords class in ISO 19115

zero o pi

(Opzionale)

fees tariffe e condizioni

per l’utilizzo di questo server

stringa di caratteri non vuota

Zero o pi

(Opzionale) access constraint vincoli e re-

strizioni sul recupero e utilizzo dei dati

String zero o più

(opzionale)

Tabella 3.2: Parametri inclusi in una sezione ServiceIdentification

Nomi Definizione Tipi di Dati Molteplicità providerName identificatore del-

l’organizzazione

String Uno

(Obbligatorio) providerSite riferimento al sito

web del fornitore del servizio

CI_OnlineResource class in ISO 19115

Zero o una

(opzionale) serviceContact Informazioni

per contattare il fornitore del servizio

CI_ResponsibleParty classes in ISO 19115

Zero o una

(opzionale)

Tabella 3.3: Parametri inclusi in una sezione ServiceProvider

Nomi Definizione Molteplicità ed uso

operation Metadati per le operazioni implementate

Uno o pi (Obbligatorio) parameter Parametrio per il dominio

applicato all’operazione

Zero o una (opzionale) constraint Vincoli sui domin Zero o una (opzionale) extendedCapabilities Metadati relativi al server

e a software supplemen- tari

Zero o una (opzionale)

Tabella 3.4: Parametri inclusi in una sezione OperationsMetadata

Nome Elemento Descrizione

Insert L’elemento <Insert> usato per indicare che il wfs è capace di creare nuove istanze di un future type.

Update L’elemento <Update> indica che il WFS può cambiare lo stato esistente di una feature.

Delete L’elemento <Delete> indica che il WFS può cancellare o rimuovere istanze di una future typt dal datastore.

Query L’elemento <Query> indica che il WFS è capace di eseguire un interrogazione su un feature type

Lock L’elemento <Lock> indica che il WFS è capace di fare il lock ad una istanza di una feature type.

Tabella 3.5: Azioni di transizione e interrogazione su Feature

3.1 OpenGIS

Web Feature Service 15

Elemento Descrizione

Name Il namespace qualifica il nome della feature type.

(obbligatorio)

Title <Title> è un titolo leggibile da una persona per identificare brevemente la feature type.

Abstract <Abstract> è una descrizione narrativa per più informazioni riguardanti la feature type.

Keyword <Keyword> contiene parole per aiutare la ricerca.

DefaultSRS <DefaultSRS> indica quale sistema di riferimento spaziale viene usato dal WFS in modo di default.

OtherSRS <OtherSRS> usato per indicare altri SRS supportati.

NoSRS <NoSRS> usato per feature type che non hanno proprietà spaziali.

Operations <Operations> definisce quali operazioni sono supportate su una feature type. Ogni operazione definita localmente ha la precedenza sulle operazioni definite globalmente.

OutputFormats Questa è una lista di MIME type indicando il formato di output che può essere generato.

WGS84BoundingBox L’elemento <WGS84BoundingBox> è usato per indicare il Bounding Box in WGS84.

MetaDataURL Un WFS può usare zero o più elementi <MetaDataURL>

per offrire altri dettagli.

Tabella 3.6: Elementi per descrivere le FeatureType

3.2 OpenGIS ^® Filter Encoding

Una espressione di filtro è un costrutto usato per vincolare i valori delle pro- prietà di un tipo di oggetto al fine di identificare un sottoinsieme di istanze per essere. L’intento di questo capitolo è quello di descrivere la codifica XML del catalogo OGC Common Query Language (CQL) come una rappresentazione neutrale di una query. Utilizzando gli strumenti per XML, è possibile convali- dare, analizzare e trasformare facilmente in un altro linguaggio per recuperare o modificare le istanze di oggetti conservati in un archivio e/o in un database.

Per esempio, un documento XML codificato come filtro potrebbe essere trasfor- mato in una clausola WHERE di un’istruzione SQL SELECT per recuperare i dati memorizzati in un database relazionale basato su SQL, allo stesso modo potrebbe essere trasformato in un XPath o espressione XPointer per il recu- pero dei dati da documenti XML. Una vasta classe di servizi web OpenGIS

, richiedono la capacità di esprimere le espressioni di filtro in XML.

3.2.1 Elementi Filter Encoding

L’elemento <filter> è l’elemento radice e contiene l’espressione che viene cre- ata combinando gli elementi definiti dal seguente frammento XML Schema:

< x s d : c o m p l e x T y p e name= " F i l t e r T y p e " >

< x s d : c h o i c e >

< x s d : e l e m e n t r e f = " o g c : s p a t i a l O p s " / >

< x s d : e l e m e n t r e f = " o g c : c o m p a r i s o n O p s " / >

< x s d : e l e m e n t r e f = " o g c : l o g i c O p s " / >

< x s d : e l e m e n t r e f = " o g c : _ I d " maxOccurs = " u n b o u n d e d " / >

< / x s d : c h o i c e >

< / x s d : c o m p l e x T y p e >

Gli elementi <logicalOps>3.2.1, <comparisonOps>3.2.1 e <spatialOps>3.2.1 sono riferimenti a gruppi per gli operatori logici, spaziali e di confronto. Gli op- eratori logici possono essere utilizzati per combinare gli operatori spaziali e di confronto nell’espressione di filtro. L’elemento <_id> ,invece ,è il riferimento per gli identificatori di un oggetto 3.2.1.

Spatial operators

Un operatore spaziale determina se i suoi argomenti geometrici rispettano la re-

lazione spaziale dichiarata. L’operatore restituisce TRUE se la relazione spaziale

è soddisfatta ,in caso contrario, restituisce FALSE.

3.2 OpenGIS

Filter Encoding 17 Gli operatori spaziali codificati sono: Disjoint ,Touches ,Within ,Overlaps ,Cross- esm ,Intersects ,Contains ,DWithin ,Beyond ,BBOX.

Si appresta a definire il solo elemento <BBOX> dato l’uso nella fase implemen- tativa del progetto, è definito come un modo conveniente e più compatto di cod- ifica del rettangolo di selezione basato sulla geometria gml:Envelope, è equiv- alente al funzionamento spaziale <Not> <Disjoint> . . . </Disjoint> </Not> il che significa che l’operatore <BBOX> deve individuare tutte le geometrie che spazialmente interagiscono nella finestra. Se l’elemento opzionale <property- Name> non è specificato, il servizio deve determinare quale struttura è la chiave spaziale e applicare l’operatore BBOX di conseguenza.

Comparison operators

Un operatore di confronto viene utilizzato per formare espressioni che resti- tuiscono il confronto matematico tra due argomenti. Se gli argomenti soddis- fano il confronto, l’espressione restituisce TRUE. In caso contrario, restituisce FALSE.

Gli operatori di confronto sono: PropertyIsEqualTo ,PropertyIsNotEqualTo ,Prop- ertyIsLessThan ,PropertyIsGreaterThan ,PropertyIsLessThanOrEqualTo ,Prop- ertyIsGreaterThanOrEqualTo ,PropertyIsLike ,PropertyIsNull ,PropertyIsBetween.

Logical operators

Un operatore logico può essere usato per combinare una o più espressioni con- dizionali. L’operatore logico AND restituisce TRUE se tutte le espressioni combinate restituiscono TRUE. l’operatore OR restituisce TRUE se una delle espressioni combinate restituiscono TRUE. L’operatore NOT inverte il valore logico di un’espressione.

Gli elementi <And> ,<Or> e <Not> possono essere usati per combinare espres- sioni logiche in modo da formarne altre più complesse.

Object identifiers

L’identificatore di un oggetto serve a rappresentare un identificatore univoco per un’istanza di un oggetto all’interno del contesto del servizio web. Ques- ta specifica non definisce un elemento specifico per identificare gli oggetti, ma definisce invece l’elemento astratto <_id> come un elemento per poi essere sos- tituito ed utilizzato alla definizione di un nuovo elemento identificatore per i tipi di oggetto specifico.

L’elemento <FeatureId> introdotte nella versione 1.0.0 identifica le istanze a

partire dalla versione dei documenti GML2 utilizzando l’attributo “FID”. Con

la versione GML 3.0, l’attributo FID è stato deprecato in favore di uno nuovo

“gml:id” che può essere utilizzato per identificare gli elementi di tipo complesso GML in aggiunta alle funzioni, quali geometrie, topologie e gli attributi comp- lessi. Un nuovo elemento viene quindi introdotto <GmlObjectId> per identifi- care gli elementi in versione GML3. L’elemento <FeatureId> viene mantenuto per retrocompatibilità.

Expressions

Un’espressione è una combinazione di uno o più simboli che restituiscono il valore booleano unico TRUE o FALSE.

Un’espressione può essere formata con gli elementi:

Arithmetic operators <Add>, <Sub>, <Mul>, <Div> :

Gli elementi sono utilizzati per codificare le operazioni aritmetiche fon- damentali di addizione, sottrazione, moltiplicazione e divisione. Gli op- eratori aritmetici sono operatori binari e accettano due argomenti e resti- tuiscono un unico risultato.

<PropertyName> :

L’elemento è usato per codificare il nome di qualsiasi proprietà di un oggetto. Il nome della proprietà può essere usato in espressioni scalari o spaziali per rappresentare il valore di quella proprietà per una particolare istanza di un oggetto.

<Literal> :

Si definisce con questa modalità la codifica del filtro con valori letterali.

Un valore letterale è una parte di una comunicazione o di espressione che deve essere utilizzato esattamente come è specificato, piuttosto che come una variabile o un altro elemento.

L’elemento <literal> è usato per codificare i valori scalari e geometrici.

I valori letterali geometrici devono essere codificati come contenuto del- l’elemento <literal>, secondo gli schemi GML [2].

<Function> :

Si definisce la codifica di funzioni a valore singolo utilizzando l’elemen- to <Function>. Una funzione è una procedura chiamata che esegue un calcolo distinto. Una funzione può accettare zero o più argomenti come input e genera un unico risultato.

Una funzione è composta dal nome della funzione, codificata con il nome dell’attributo, e zero o più argomenti contenuti all’interno dell’elemento

<Function>.

3.3 OpenGIS

Styled Layer Descriptor 19 L’elemento <expression> è un elemento astratto, il che significa che in realtà non esiste e il suo unico scopo è quello di agire come segnaposto per gli ele- menti e le combinazioni di elementi che possono essere utilizzati per formare espressioni.

3.3 OpenGIS ^® Styled Layer Descriptor

La possibilità di ricevere mappe o informazioni sui contenuti della mappa non è solo l’unica caratteristica degli standard definiti dall’OGC e visti nelle sezioni precedenti. Finora si è analizzato solo il modo di inviare richieste e ricevere risposte da parte di un server georeferenziale, ma non si è descritto come si deve operare per visualizzare l’informazione con un determinato tematismo scelto dall’utente. Non essendo stato ideato per questo caso, gli standard WMS e WFS non comprendono le direttive necessarie per creare tematismi, per questo motivo OGC ha implementato un altro standard denominato Styled Layer De- scriptor (SLD).

Come si intuisce dal nome, con questo linguaggio è possibile creare tematiz- zazioni di punti, linee, poligoni, etichette di testo e molto altro ancora. SLD è quindi una sofisticata specifica OGC per la vestizione di layer vettoriali e raster. La tematizzazione avviene grazie all’utilizzo di elementi di tipo XML definiti tramite un XML Schema, ognuno con i propri parametri e le proprie funzionalità, tra cui la possibilità di utilizzare alcuni parametri dei CSS. L’SLD è un linguaggio molto flessibile, anche se nella sua generalità risulta di diffi- cile comprensione infatti non ha una sintassi semplificata per i tipi di rendering più comuni. Una volta presa padronanza dello strumento si possono realizzare stili piuttosto sofisticati che riescono a soddisfare sia le specifiche GML che le specifiche Filter.

Attualmente esistono due versioni di SLD che vengono utilizzate per creare le tematizzazioni, ovverosia la 1.0.0 e la 1.1.0. Di norma la versione usata dalla maggior parte degli OpenGIS Web Server è la 1.0.0, a differenza della 1.1.0 ancora poco supportata.

Innanzitutto bisogna sottolineare che lo standard SLD è intrecciato di default allo standard WMS. Infatti, se si utilizza la direttiva GetMap di WMS si nota come lo styling SLD possa essere utilizzato in tre diversi modi:

• Il Client interagisce con il Server WMS attraverso il protocollo HTTP

GET. Il file SLD viene utilizzato in modalità remota grazie all’aggiunta

del parametro SLD=url_file_sld& nella query;

• Il Client usa sempre HTTP GET ma inserisce il contenuto XML dell’SLD direttamente nella query attraverso il parametro SLD_BODY (con dovute codifiche);

• Il Client interagisce con il server WMS attraverso HTTP POST, con la richiesta GetMap codificata in XML includendo anche il corpo dell’SLD;

Il terzo metodo è tecnicamente superiore rispetto agli altri due, purtroppo però non è implementato da quasi tutte le tecnologie lato server disponibili. L’utiliz- zo del secondo metodo, che è un compromesso tra il primo e il terzo metodo può comportare dei problemi nell’eccessiva lunghezza dell’URL. Di norma si utiliz- za il primo metodo, che è il più efficiente. Come annunciato precedentemente, lo standard Styled Layer Descriptor non è altro che una definizione di parametri grafici basati sul linguaggio XML. Gli elementi utilizzabili sono stati definiti at- traverso l’utilizzo dell’SLD Schema (ovverosia un semplice XML Schema) che ne definisce la grammatica. Tali elementi XML, che verranno analizzati, sono:

• StyledLayerDescriptor (elemento radice)3.3.1

• Named Layer 3.3.1

• User-Defined Layer 3.3.1

• User-Defined Style 3.3.1

• FeatureTypeStyle 3.3.1

• Rule 3.3.1

• Symbolizer: poligoni 3.3.1

3.3.1 Elementi SLD

Un documento SLD è definito come una sequenza di styled layers. La radice StyledLayerDescriptor è definita dalla seguente frammento di XML Schema:

< x s : e l e m e n t name= " S t y l e d L a y e r D e s c r i p t o r " >

< x s : c o m p l e x T y p e >

< x s : c h o i c e m i n O c c u r s = " 0 " maxOccurs = " u n b o u n d e d " >

< x s : e l e m e n t r e f = " s l d : N a m e d L a y e r " / >

< x s : e l e m e n t r e f = " s l d : U s e r L a y e r " / >

< / x s : c h o i c e >

< x s : a t t r i b u t e name= " v e r s i o n " t y p e = " x s : s t r i n g "

u s e = " r e q u i r e d " / >

3.3 OpenGIS

Styled Layer Descriptor 21

< / x s : c o m p l e x T y p e >

< / x s : e l e m e n t >

L’attributo version fornisce la versione del documento SLD, per facilitare la compatibilità con i documenti statici archiviati in diverse versioni della specifi- ca. La stringa nel formato “x.y.z”, è la stessa che nelle altre specifiche dei web server definite dall’OpenGIS. L’attributo è obbligatorio.

Gli styled layers possono corrispondere a NamedLayer o layer definiti dall’u- tente (UserLayer), che sono descritti nelle sezioni successive. Ci può essere un numero qualsiasi di entrambi i tipi di styled layer, anche nessuno, in qual- siasi ordine. L’ordine a cui i layer compaiono nel documento SLD sarà l’or- dine che gli styled layers sono presentati, con i successivi styled layers saranno renderizzati rispetto al styled layers precedente.

Named Layers

Un “layer” è definito come un insieme di caratteristiche che possono essere potenzialmente di vari tipi di elementi. Un named layer è un livello che si può accedere da un web server OpenGIS utilizzando un nome noto.

User-Defined Layers

Oltre a utilizzare i named layers, è anche utile per essere in grado di definire layer personalizzati per il rendering. Dal momento che un layer è definito come un insieme di caratteristiche potenzialmente di tipo misto, l’elemento UserLay- er deve fornire i mezzi per identificare le caratteristiche per essere utilizzato.

Tutte le feature che devono essere rese per essere poi prelevate da una Web Feature Server (WFS) o un Web Coverage Service.

User-Defined Styles

Uno stile definito dall’utente consente lo styling della mappa per essere definito esternamente dal sistema e per essere passati in giro in un frammento inter- operabile in formato XML. The per l’elemento SLD UserStyle lo schema è il seguente:

< x s : e l e m e n t name= " U s e r S t y l e " >

< x s : c o m p l e x T y p e >

< x s : s e q u e n c e >

< x s : e l e m e n t r e f = " s l d : N a m e " m i n O c c u r s = " 0 " / >

< x s : e l e m e n t r e f = " s l d : T i t l e " m i n O c c u r s = " 0 " / >

< x s : e l e m e n t r e f = " s l d : A b s t r a c t " m i n O c c u r s = " 0 " / >

< x s : e l e m e n t r e f = " s l d : I s D e f a u l t " m i n O c c u r s = " 0 " / >

< x s : e l e m e n t r e f = " s l d : F e a t u r e T y p e S t y l e "

maxOccurs = " u n b o u n d e d " / >

< / x s : s e q u e n c e >

< / x s : c o m p l e x T y p e >

< / x s : e l e m e n t >

< x s : e l e m e n t name= " T i t l e " t y p e = " x s : s t r i n g " / >

< x s : e l e m e n t name= " A b s t r a c t " t y p e = " x s : s t r i n g " / >

< x s : e l e m e n t name= " I s D e f a u l t " t y p e = " x s : s t r i n g " / >

Un UserStyle è allo stesso livello semantico di un NamedStyle utilizzati nel contesto di un WMS. Gli elementi Name, Title e Abstract consentono ad uno stile definito dall’utente di essere identificati e sono opzionali. Il nome dato è equivalente al nome di uno stile denominato WMS e viene usato come riferiri- mento allo stile ed identifica lo stile chiamato. Il titolo è una breve descrizione leggibile per lo stile che possono essere visualizzati in un elenco, e l’Abstract è una descrizione più precisa che può essere di pochi paragrafi.

Un UserStyle può contenere uno o più FeatureTypeStyles che permettono il rendering delle caratteristiche di tipi specifici.

FeatureTypeStyles

Il FeatureTypeStyle definisce lo stile che deve essere applicato ad una singola feature type di un layer. Esso è definito come segue:

< x s : e l e m e n t name= " F e a t u r e T y p e S t y l e " >

< x s : c o m p l e x T y p e >

< x s : s e q u e n c e >

< x s : e l e m e n t r e f = " s l d : N a m e " m i n O c c u r s = " 0 " / >

< x s : e l e m e n t r e f = " s l d : T i t l e " m i n O c c u r s = " 0 " / >

< x s : e l e m e n t r e f = " s l d : A b s t r a c t " m i n O c c u r s = " 0 " / >

< x s : e l e m e n t r e f = " s l d : F e a t u r e T y p e N a m e " m i n O c c u r s =

" 0 " / >

< x s : e l e m e n t r e f = " s l d : S e m a n t i c T y p e I d e n t i f i e r "

m i n O c c u r s = " 0 " maxOccurs = " u n b o u n d e d " /

>

< x s : e l e m e n t r e f = " s l d : R u l e " maxOccurs = " u n b o u n d e d "

/ >

3.3 OpenGIS

Styled Layer Descriptor 23

< / x s : s e q u e n c e >

< / x s : c o m p l e x T y p e >

< / x s : e l e m e n t >

L’elemento FeatureTypeStyle identifica la separazione esplicita nella SLD tra il trattamento di ‘layer’ e il trattamento delle feature type specifica. Il concetto di

‘layer’ è unica per WMS e SLD, ma le feature sono usate più in generale, come in WFS e GML, in modo esplicito questa separazione è importante.

Come in UserStyle, le FeatureTypeStyle possono avere un Name, Title, e Ab- stract.

Il FeatureTypeName identifica il tipo specifico di feature ed è lo stile ad essa as- sociata. Il FeatureTypeStyle contiene uno o più elementi Rule che consentono il rendering condizionale.

Rules

Le Rules sono utilizzate per raggruppare le istruzioni per il rendering da con- dizioni sulle proprietà delle feature e dalla scala della mappa. Un esempio del formato di una Rule è mostrato nel seguente frammento XML Schema:

< x s : e l e m e n t name= " R u l e " >

< x s : c o m p l e x T y p e >

< x s : s e q u e n c e >

< x s : e l e m e n t r e f = " s l d : N a m e " m i n O c c u r s = " 0 " / >

< x s : e l e m e n t r e f = " s l d : T i t l e " m i n O c c u r s = " 0 " / >

< x s : e l e m e n t r e f = " s l d : A b s t r a c t " m i n O c c u r s = " 0 " / >

< x s : e l e m e n t r e f = " s l d : L e g e n d G r a p h i c " m i n O c c u r s = " 0

" / >

< x s : c h o i c e m i n O c c u r s = " 0 " >

< x s : e l e m e n t r e f = " o g c : F i l t e r " / >

< x s : e l e m e n t r e f = " s l d : E l s e F i l t e r " / >

< / x s : c h o i c e >

< x s : e l e m e n t r e f = " s l d : M i n S c a l e D e n o m i n a t o r "

m i n O c c u r s = " 0 " / >

< x s : e l e m e n t r e f = " s l d : M a x S c a l e D e n o m i n a t o r "

m i n O c c u r s = " 0 " / >

< x s : c h o i c e m i n O c c u r s = " 0 " maxOccurs = " u n b o u n d e d " >

< x s : e l e m e n t r e f = " s l d : L i n e S y m b o l i z e r " / >

< x s : e l e m e n t r e f = " s l d : P o l y g o n S y m b o l i z e r " / >

< x s : e l e m e n t r e f = " s l d : P o i n t S y m b o l i z e r " / >

< x s : e l e m e n t r e f = " s l d : T e x t S y m b o l i z e r " / >

< x s : e l e m e n t r e f = " s l d : R a s t e r S y m b o l i z e r " / >

< / x s : c h o i c e >

< / x s : s e q u e n c e >

< / x s : c o m p l e x T y p e >

< / x s : e l e m e n t >

Solo una singola feature può essere all’interno di una Rule.

Gli elementi Filter e ElseFilter di una Rule permettono la selezione delle feature come descritto in 3.2.

L’elemento filtrante ha un significato relativamente semplice. La sintassi del- l’elemento filtrante è definito nella nello standard [3]. I filtri possono essere utilizzati in diversi modi ed applicabili allo stesso FeatureTypeStyle possono sovrapporsi in termini di funzionalità e selezionate di ogni Rule.

Se una Rule non ha alcun elemento di filtrante, la condizione della Rule è sem- pre valida per tutte le feature sono accettate e vengono inserite nello stile dalla Rule.

Symbolizers

All’interno di una Rule, per le condizioni per gli stili agli elementi vengono uti- lizzati i Symbolizers. Un symbolizer descrive il modo di apparire una feature su una mappa. Il symbolizer non descrive solo la forma che dovrebbe apparire, ma anche le propriet grafiche come il colore e l’opacit. Attualmente, sono definiti cinque tipi di symbolizers:

• Line

• Polygon

• Point

• Text

• Raster

In questa sezione verr solo descritto il tipo Poligon usato per il progetto.

Polygon Symbolizer Un PolygonSymbolizer viene utilizzato disegnare un poligono (o altre geometrie di tipo area), compresi il suo riempimento al suo interno e ed il suo bordo(contorno). Essa ha la seguente definizione:

< x s : e l e m e n t name= " P o l y g o n S y m b o l i z e r " >

< x s : c o m p l e x T y p e >

< x s : s e q u e n c e >

< x s : e l e m e n t r e f = " s l d : G e o m e t r y " m i n O c c u r s = " 0 " / >

3.4 OpenGIS

CityGML 25

< x s : e l e m e n t r e f = " s l d : F i l l " m i n O c c u r s = " 0 " / >

< x s : e l e m e n t r e f = " s l d : S t r o k e " m i n O c c u r s = " 0 " / >

< / x s : s e q u e n c e >

< / x s : c o m p l e x T y p e >

< / x s : e l e m e n t >

L’elemento Geometry definisce la geometria da utilizzare per lo styling. L’u- nico metodo disponibile per la definizione di una geometria fare riferimento a una propriet di geometria utilizzando l’elemento ogc:PropertyName(definiti dal WFS). Il riempimento(Fill) e il tratto(Stroke) sono contenuti nel PolygonSym- bol.

3.4 OpenGIS ^® CityGML

CityGML nasce come metodo generale per la strutturazione di modelli per am- bienti urbani con scopi di visualizzazione, comprendendo oltre alle geometrie degli oggetti anche le loro proprietà semantiche e tematiche.

Definisce classi e relazioni per gli oggetti topografici più rilevanti nei mod- elli di città e regioni riguardanti le loro proprietà geometriche, topologiche, semantiche e il loro aspetto esterno.

Sono incluse generalizzazioni gerarchiche tra classi tematiche, aggregazioni, relazioni tra oggetti e proprietà spaziali. Le informazioni tematiche messe a disposizione fanno si che CityGML non sia semplicemente un formato per lo scambio e la visualizzazione di dati 3D dei modelli urbani, ma permette di usare tali modelli per analisi più sofisticate in ambiti applicativi diversi: simulazioni, data mining urbano, informazioni tematiche.

CityGML è un modello di dati aperto e basato su XML per memorizzare e scambiare dati spaziali 3D. Si tratta di uno schema basato sulla versione 3.1.1 di Geography Markup Language (GML3), standard internazionale per lo scambio di dati territoriali rilasciato dall’Open Geospatial Consortium (OGC) e la ISO TC211.

L’obiettivo di CityGML è quello di raggiungere una definizione comune delle entità di base, attributi e le relazioni di un modello 3D di una città. Questo è particolarmente importante per quanto riguarda la manutenzione e sostenibil- ità dei modelli 3D, consentendo il riutilizzo degli stessi dati in diversi campi applicativi.

Le parti principali di questo linguaggio sono il modello geometrico e il mod-

ello tematico. Il primo rappresenta tutte le informazioni di tipo geometrico

e topologico in tre dimensioni degli oggetti del modello, mentre il secondo in-

clude informazioni di tipo semantico, che aiutano l’utente a stabilire le relazioni

tra i vari oggetti del modello, e utilizza il modello geometrico per modellare di- versi oggetti tematici, ad esempio: “Digital Terrrain model”, vegetazione [veg- etation] ( oggetti isolati e a allo stesso tempo una loro aggregazione), bacini idrici [water bodies], rete stradale[transportation facilities] e arredo urbano[city furniture].

Tutto ciò che non è esplicitamente modellato dallo standard è modellabile attraverso il concetto di oggetti generici e da attributi. Oggetti che hanno stessa forma e che appaiono molte volte anche in posizioni diverse, come gli alberi, possono essere modellati come prototipi e usati pù volte nel modello.Inoltre il concetto di TerrainIntersectionCurve è introdotto per integrare oggetti 3D con il Digital Terrain Model per avere le posizioni corrette al fine di evitare ad esempio edifici galleggianti e affossamenti nel terreno.

CityGML distingue cinque diversi livelli di dettaglio (LOD), in cui gli ogget- ti, all’aumentare del livello di dettaglio, diventano sempre più dettagliati sia dal punto di vista geometrico che tematico. Inoltre, gli oggetti possono avere delle referenze esterne corrispondenti ad oggetti in dataset esterni. Infine, agli oggetti CityGML è possibile assegnare un aspetto esteriore (appearances). Le apparen- ze non sono solo proprietà visive ma rappresentano anche proprietà osservabili arbitrarie delle superfici quali rumore, l’inquinamento o problemi strutturali indotti, ad esempio, da un terremoto.

Per una trattazione accurata di veda [1].

3.4.1 Caratteristiche generali

Modularisation

Il modello CityGML consiste nella definizioni di classi per i più importanti tipi di oggetti del modello cittadino 3D. Queste classi sono state individuate per essere necessarie ed importanti in molte applicazioni per diverse aree.

Il modello CityGML è scomposto in core module e thematic extension mod- ules. Il core module comprende i concetti e le componenti di base di CityGML e, quindi, deve essere implementato da qualsiasi sistema. Basati sul core mod- ule, ogni estensione copre una tematica specifica di un campo del modello vir- tuale 3D della città. CityGML introduce le seguenti undici moduli tematici estensione: Appearance, Building, CityFurniture, CityObjectGroup, Generics, LandUse, Relief, Transportation, Vegetation, WaterBody.

Le implementazioni di CityGML possono supportare qualsiasi combinazione

dei moduli di estensione in combinazione con il core module. Tali combinazioni

di moduli sono denominati CityGML profiles. Pertanto, CityGML consente di

implementare anche solo parzialmente il modello globale CityGML in modo

valido.

3.4 OpenGIS

CityGML 27

Multi-scale modelling (5 levels of detail, LOD)

CityGML supporta cinque diversi livelli di dettaglio (LOD). All’aumentare del livello di dettaglio gli oggetti diventano sempre più particolareggiati sia per quel che riguarda la geometria sia per la tematica.

I diversi LOD sono:

• LOD0 : modello regionale (2.5D modello di terreno);

• LOD1: città/modello del sito (modello di blocco con o senza tetti);

• LOD2: città/modello del sito (texture di tetti e delle facciate);

• LOD3: città/modello del sito (modello architetturale dettagliato);

• LOD4: modello dell’interno (navigazione all’intero dell’edificio).

Ogni file CityGML può, ma non deve necessariamente, contenere rappresen- tazioni multiple per ogni oggetto in un diverso livello di dettaglio simultanea- mente.

Figura 3.1: Esempio di LOD

City object groups

Il concetto di raggruppamento in CityGML permettere l’aggregazione di ogget- ti secondo criteri definiti dall’utente, e per rappresentare e trasferire queste ag- gregazioni come parte di un modello unico. Un gruppo può contenere altri grup- pi come membri, permettendo raggruppamento nidificato di profondità arbi- traria. Il concetto raggruppamento è espresso dall’estensione CityObjectGroup di CityGML.

Prototypic objects / scene graph concepts

In CityGML oggetti con forma uguale come gli alberi, semafori, segnali stradali, ecc. possono essere rappresentati come prototipi che vengono istanziati più volte in luoghi diversi. La geometria del prototipi è definita in un sistema di coordinate locali. Ogni istanza è rappresentata da un riferimento al prototipo, un punto base del sistema di coordinate di riferimento e una matrice di trasfor- mazione che facilita il ridimensionamento, rotazione, e la traduzione del pro- totipo. Il principio è adottato dal concetto di scena utilizzati negli standards della computer graphics come VRML e X3D. Poiché GML3 non fornisce il supporto per la scena, questo è implementato come estensione di GML3.

3.4.2 modellazione geometrica e semantica

Uno dei più importanti principi di progettazione di CityGML è la coerenza tra la modellazione semantica e le proprietà geometriche/topologiche.

A livello semantico gli oggetti del mondo reale sono rappresentati da ‘cose’

come: edifici, muri, finestre o stanze. La loro descrizione include: attributi, re- lazioni ed aggregazioni gerarchiche tra oggetti. Quindi la parte di relazioni tra gli oggetti può essere derivata solo a livello semantico e non geometrico. A liv- ello spaziale, gli oggetti geometrici sono assegnati ad oggetti che rappresentano la loro locazione ed estensione nello spazio.

Quindi il modello è compostato da due livelli gerarchici:

• semantico

• geometrico

in cui gli oggetti corrispondenti sono legati tra loro da relazioni di tipo gerar- chico.

Il vantaggio di questo approccio consiste nel fatto che è possibile effettuare

una navigazione in entrambe le gerarchie e tra le gerarchie arbitrariamente, per

poter eseguire query tematiche e/o geometriche.

Capitolo 4

Tecnologie utilizzate

4.1 PostgreSQL/PostGIS

PostgreSQL

è un sistema di gestione di database relazionale ad oggetti (OR- DBMS) basato su POSTGRES, Version 4.2

, sviluppato alla “University of California”, nel dipartimento di informatica Berkeley. POSTGRES propone- va molti concetti che diventarono disponibili solo in alcuni sistemi di database commerciali molto più tardi.

PostgreSQL

è il discendente open-source di quel codice originale Berke- ley. Supporta una parte molto grande dello standard SQL e offre molte altre funzionalità:

• query complesse

• chiavi esterne

• trigger

• viste

• integrità transazionale

• controllo concorrente multiversione

Inoltre, PostgreSQL

può essere esteso dall’utente in molti modi, per esempio aggiungendo nuovi tipi di dato, funzioni, operatori, funzioni aggregate, metodi di indice, linguaggi procedurali.

Data la licenza libera, PostgreSQL

può essere usato, modificato e distribuito

da chiunque gratuitamente per qualsiasi scopo, sia esso privato, commerciale,

o accademico.

PostGIS è l’estensione spaziale del server PostgreSQL che introduce i tipi di dato geometrico e le funzioni per lavorare con essi. Inoltre fornisce le definizioni dei sistemi di coordinate (derivati dalla classificazione EPSG) per eseguire trasfor- mazioni tra geometrie materializzate in sistemi di riferimento diversi.

Attenendosi ai formati descritti da Open Geospatial Consortium , per garantire trasparenza ed interoperabilità, vengono usati i tipi: POINT, MULTIPOINT, LINESTRING, MULTILINESTRING, POLYGON, MULTIPOLYGON, GE- OMETRYCOLLECTIONS (più le estensioni SQL-MM CIRCULARSTRING, COMPOUNDCURVE, CURVEPOLYGON, MULTICURVE, MULTISURFACE) con estensione XYZ,XYM, XYZM.

Per ogni strato informativo occorre definire una colonna che contenga le coor- dinate, ed un sistema che gestisca in maniera differenziata le tabelle che con- tengono dati geometrici di tipo differente. Occorre inoltre introdurre un in- sieme di vincoli per verificare che i dati inseriti siano congruenti: ad esempio dovrebbe essere sempre verificata la bi o tri-dimensionalità nello stesso dataset.

Interrogazioni veloci alle tabelle sono la ragione d’essere dei database (assieme al supporto per le transazioni). I database si differenziano proprio per la mag- gior robustezza e prestanza degli indici. Le elaborazioni GIS avvengono us- ando la sintassi SQL sui costrutti “spaziali”. Esistono comunque funzioni che costruiscono immediatamente tutta la struttura necessaria alla gestione dei dati territoriali. Analogamente le interrogazioni al database avvengono utilizzando

“SQL query” utilizzando combinazioni di dati e funzioni e di test vero/falso.

Per comprendere come funzioni una query spaziale occorre tenere presenti due cose:

1. esistono gli indici spaziali;

2. le interrogazioni spaziali sono molto dispendiose in termini di calcolo se effettuate su un gran numero di entità geometriche.

Gli indici spaziali esistono per migliorare l’efficienza delle query. I dati ge- ografici vengono “aggregati” e “amministrati” in gruppi spaziali distinti. In questo senso gli indici sono lossy: sono definiti per semplificare e nella sem- plificazione perdono informazioni. Ad esempio: spesso si vuole utilizzare l’- operatore intersezione && che testa se il rettangolo che circoscrive le entità geometriche ne intersechi altre. Questa funzione è ottimizzata per l’utilizzo degli indici spaziali: serve a scremare i dati per esegure una ricerca più raffina- ta usando le funzioni Distance, Intersects, Contains, Within. . . Le funzioni che utilizzano l’indice spaziale servono per identificare le geometrie che possono soddisfare ad una condizione. Le funzioni spaziali testano la condizione esatta- mente.

PostgreSQL utilizza 3 tipi di indici: B-Tree, R-Tree e GiST (Generalized Search

4.2 Geoserver 31

Tree). Per PostgreSQL, R-Tree ha l’inconveniente di NON essere “null safe”:

non possono essere immagazzinate geometrie NULLE, degeneri o tipi diversi all’interno della stessa colonna. Sinteticamente, PostGIS manipola dati “con- gruenti”.

4.2 Geoserver

Geoserver è un software open source, Java-based, che permette ai suoi utenti di visualizzare, modificare e condividere dati geospaziali attraverso l’utilizzo di protocolli definiti dall’ OGC.

GeoServer è nato nel 2001 da “The Open Planning Project” (TOPP), un proget- to con sede a New York ideato per creare una suite di strumenti che rendessero l’attività del governo più trasparente. Con GeoServer nacque anche il progetto GeoTools, una libreria Java sviluppata per consentire a GeoServer di lavorare con vari formati vettoriali e geoDBMS.

GeoTools toolkit è tuttora sfruttato da GeoServer ed è caratterizzato da un’ar- chitettura modulare che permette di aggiungere funzionalità in modo agevole, è rilasciato sotto GNU Lesser General Public Licence (LGPL) e contiene metodi standard compliant per la manipolazione di dati spaziali. Contestualmente allo sviluppo di GeoServer infatti, OGC stava lavorando allo standard Web Feature Service (WFS), un protocollo per rendere i dati spaziali direttamente disponi- bili sul web usando GML (Geographic Markup Language, la grammatica XML definita sempre dall’OGC per specificare le caratteristiche di oggetti geografi- ci).

Altri progetti che nacquero proprio per rafforzare le funzionalità di GeoServer sono:

• Refractions Research, che realizzò PostGIS, un database spaziale che abilita GeoServer alla connessione ai database.

• MetaCarta, ideò invece Open Layers, una libreria Java Script open source.

Tale libreria è tuttora integrata in GeoServer e rilasciata sotto la licenza BSD-style; è in continuo sviluppo e rende la generazione delle mappe e la visualizzazione delle stesse nei moderni web browser, facile e veloce.

La prima versione di GeoServer (1.0) è stata rilasciata nell’ottobre del 2001.

SourceForge.net (al momento il più grande sito di sviluppo e controllo di soft- ware open source), in quel mese, registrò circa 500 download del pacchetto GeoServer.

Poco dopo il rilascio della prima versione, che implementava solo la specifica

WFS definita da OGC, un programmatore di un’azienda commerciale spagnola sviluppò il supporto per la specifica Web Map Service (WMS), un protocollo per la creazione e visualizzazione di mappe create a partire da dati spaziali.

Successivamente altri progetti hanno contribuito ad incrementare le funzional- ità di questo server geospaziale. Nel 2005 la compagnia italiana GeoSolutions sviluppò il supporto per lo standard Web Coverage Services (WCS) e per la grafica raster che rappresenta le immagini descrivendole come una griglia di pixel opportunamente colorati (contrapposta alla grafica vettoriale che invece descrive le immagini attraverso primitive geometriche che definiscono punti, linee e poligoni ai quali possono essere attribuiti colori e sfumature).

Nell’agosto del 2007 è stata poi rilasciata la versione 1.5.3 e sono stati registrati approssimativamente 8500 download. Al crescere di questi ultimi e dei progetti sviluppati intorno a GeoServer, corrispondeva la crescita del numero di utenti e sviluppatori.

Il successo di GeoServer è dovuto proprio al fatto che, essendo un progetto open source, la sua gestione è sempre stata delegata a tutta la comunità (formata da soggetti provenienti da diverse organizzazioni) e mai a una singola organiz- zazione.

La versione corrente è la 2.0.2, rilasciata il 24 Maggio 2010 ed è già disponibile la versione 2.1 Beta (4 Settembre 2010).

Lo sviluppo di GeoServer continua per rendere i dati spaziali accessibili a tutti.

In questo senso, sta lavorando con Google per rendere i propri dati accessibili e ricercabili attraverso Google Map. Presto, ricercare dati spaziali diventerà quindi facile come cercare una pagina web su Google.

4.2.1 Struttura catalogo

La directory dati di GeoServer è la posizionata nel file system dove GeoServer memorizza tutta la sua configurazione.

Questa configurazione definisce come: quali dati GeoServer fornisce, dove sono collocati i dati, come i servizi (WMS e WFS) interagiscono con i server e con i dati. La directory contiene anche una serie di file di supporto utilizzati da GeoServer per vari scopi. In generale gli utenti non ha bisogno di conoscere la struttura delle directory dei dati, ma è una buona idea definire una directory esterna per i dati, per rendere più semplice l’aggiornamento, la produzione e la ricerca.

La struttura della directory a questo punto è quasi esclusivamente essere di

interesse per gli sviluppatori. Nelle versioni precedenti gli utenti spesso modifi-

cavano direttamente i dati e le varie configurazioni di Geoserver nella directory,

con la nuova versione 2.x.x questo è possibile con le REST API, ed è l’unica

4.2 Geoserver 33

opzione consigliata.

La struttura di una directory dati di GeoServer:

file .xml I file xml a questo livello servono per salvare le informazioni sui servizi e le varie opzioni globali.

File Descrizione

global.xml Contiene le impostazioni tra i servizi, comprese le in- formazioni sui contatti, le impostazioni JAI, set di caratteri.

logging.xml Specifica la registrazione, il luogo, e gli accessi al std out.

wcs.xml Contiene i metadati e le varie impostazioni per il servizio WCS.

wfs.xml Contiene i metadati e le varie impostazioni per il servizio WFS

wms.xml Contiene i metadati e le varie impostazioni per il servizio WMS

Tabella 4.1: File di configurazione di primo livello

workspaces La directory workspaces contiene i metadati relativi ai “layers”

che sono pubblicati da GeoServer. Ogni layer avrà un file layer.xml ad esso associati ed un xml o un file “featuretype.xml” a seconda se si tratta di un raster o vettoriale.

data Da non confondere con “GeoServer data directory”, in questa directory possono essere memorizzati effettivamente i dati, è comunemente utiliz- zata per archiviare shapefiles e file raster, ma può essere utilizzata per tutti i dati basati su file.

Il principale vantaggio di immagazzinare file dati all’interno è la portabil- ità, in modo da essere utilizzato da tutta l’utenza come path unico senza ulteriori modifiche.

demo La directory demo contiene i file che definiscono le richieste per agli esempi contenuti nel Sample Request Tool (voce Demos del menù prin- cipale di Geoserver)

geosearch La directory GeoSearch contiene le informazioni per le “regiona- tion” dei file KML.

gwc Questa directory contiene la cache creata dal servizio integrato GeoWeb-

Cache.