Rappresentazione di modelli urbani CityGML su un globo virtuale

Corso di Laurea in INFORMATICA
Tesi di Laurea
Rappresentazione di modelli urbani
CityGML su un globo virtuale
Relatore: Prof. Nicola Conci
Correlatori: Raffaele De Amicis, Daniele Magliocchetti
Laureando: Alessandro Florio – 140245
Trento, 26 settembre 2012
Prefazione
CityGML è un encoding basato sul linguaggio di markup XML che
rappresenta modelli urbani tridimensionali; fornisce un modello della città
standard ed un meccanismo per descrivere oggetti tridimensionali
considerando le loro proprietà geometriche, topologiche, semantiche ed
estetiche.
A differenza di altri formati, CityGML è basato su un modello
generalizzato molto ricco che permette di sfruttare i modelli virtuali di
città per un enorme numero di applicazioni. Inoltre si distingue da una
semplice descrizione di oggetti tridimensionali per le relazioni tra i vari
oggetti, raggruppati gerarchicamente, e le proprietà spaziali, in quanto
ogni elemento è georeferenziato.
I visualizzatori ad oggi disponibili tuttavia non sfruttano queste
potenzialità senza contestualizzarle in un ambiente, ma si limitano a
rappresentarne le geometrie. Lo scopo di questa tesi è quello di
contestualizzare i modelli urbani tridimensionali su un globo virtuale
interattivo, rispettando la loro posizione geografica e l'andamento
tridimensionale del terreno, arricchito con mappe fotorealistiche per
rendere la visualizzazione il più simile possibile alla realtà.
Tutto ciò permetterà in futuro lo sviluppo di un elevato numero di
applicazioni che richiedano di tener conto dell'ambiente in cui una città è
situata, di come una determinata zona appare, oppure della distribuzione,
forma e proprietà degli edifici.
Indice
1 Introduzione ............................................................................. 1
1.1 Contesto ............................................................................. 1
1.2 Problema ............................................................................. 1
1.3 Soluzione ............................................................................ 2
1.4 Struttura della tesi ................................................................ 2
2 Stato dell'arte ........................................................................... 3
2.1 CityGML .............................................................................. 3
2.1.1 GML ...............................................................................3
2.1.2 Struttura del CityGML ........................................................4
2.1.3 Versione utilizzata ............................................................7
2.2 NASA World Wind ................................................................. 8
2.2.1 SDK ...............................................................................8
2.2.2 GDAL ............................................................................10
2.2.3 Versioni utilizzate ............................................................10
3 Implementazione .................................................................... 11
3.1 Lettura .............................................................................. 11
3.2 Parsing .............................................................................. 13
3.2.1 Procedimento .................................................................14
3.2.2 Extra feature ..................................................................18
3.3 Ottimizzazione ................................................................... 18
3.3.1 Procedimento .................................................................19
3.3.2 Calcolo dell'inviluppo convesso ..........................................21
3.4 Rendering .......................................................................... 22
3.5 Simulatore di dinamica dei fluidi ........................................... 27
3.5.1 Clipping .........................................................................29
4 Problemi e limiti ..................................................................... 31
4.1 Coordinate Reference System ............................................... 31
4.2 Document Object Model ....................................................... 31
4.3 CityGML ............................................................................ 32
4.4 World Wind ........................................................................ 33
5 Sviluppi futuri ......................................................................... 35
5.1 Miglioramenti possibili ......................................................... 35
5.1.1 Memoria necessaria ........................................................35
5.1.2 Simulazione della dispersione di fluidi ................................35
5.1.3 Aggregazione degli edifici .................................................36
5.2 Utilizzi del programma ......................................................... 36
6 Conclusioni ............................................................................. 37
7 Ringraziamenti ....................................................................... 39
8 Appendici ................................................................................ 41
8.1 Acronimi ............................................................................ 41
8.2 Bibliografia ........................................................................ 42
8.3 Immagini ........................................................................... 42
1 Introduzione
1.1 Contesto
L'ultima generazione di UIM (Urban Information Model) tridimensionali, creata
da accurate informazioni geo-spaziali a livello urbano, può essere usata per
creare servizi basati su informazioni geometriche, semantiche, morfologiche e
strutturali. Questi servizi possono essere usati per prendere decisioni migliori
su problemi riguardanti la pianificazione urbana, la gestione di una città, la
protezione ambientale ed il consumo energetico grazie alla consapevolezza
della morfologia della città. Ad esempio, conoscendo la collocazione di una città
(latitudine, presenza di rilievi) e disposizione, forma, altezze dei suoi edifici, è
possibile studiare un posizionamento ottimale dei pannelli solari sui tetti degli
edifici, in modo da aumentarne la produzione di energia pulita.
Per poter sviluppare tali servizi è necessario avere un modello tridimensionale
della città contestualizzato in un globo anch'esso tridimensionale
sufficientemente flessibile da permettere l'integrazione con diverse
applicazioni.
1.2 Problema
La miglior rappresentazione di aree urbane per gli scopi citati nel paragrafo
precedente è data dal CityGML, un modello general-purpose e quindi ricco di
dettagli che, oltre alla descrizione – anche estetica – di edifici, può contenere
informazioni su strade, elementi architettonici e arredo urbano in generale.
Nonostante la sua ricchezza di informazioni, il modello CityGML non è ancora
sfruttabile in tutte le sue potenzialità in quanto i visualizzatori presenti ad ora
permettono soltanto di renderizzare gli oggetti come una qualunque scena
tridimensionale, senza però contestualizzare la città nel suo reale ambiente e
senza possibilità di essere ampliati per utilizzare il modello tridimensionale per
altri scopi.
1
1 Introduzione
1.3 Soluzione
1.3 Soluzione
In questa tesi verrà mostrata l'implementazione di un tool che permetterà
la visualizzazione di modelli CityGML all'interno di World Wind (WW), globo
virtuale
open-source
realizzato
dalla
NASA.
Il
linguaggio
di
programmazione utilizzato è Java, per poter sfruttare appieno le
numerosissime funzioni e strutture dati fornite dal WWJ SDK.
Il tool in questione è strutturato nelle seguenti fasi:
1. Lettura: il file contenente il modello CityGML viene letto ed i suoi nodi
vengono salvati in liste a seconda dell'elemento analizzato;
2. Parsing: i nodi salvati vengono esplorati, analizzati e le classi XML
vengono convertite in classi renderizzabili da WW;
3. Ottimizzazione: gli edifici vengono raggruppati in isolati e gli isolati in
quartieri: questo permetterà una clusterizzazione su due livelli di
gruppi di edifici quando questi sono in lontananza e quindi poco
distinguibili, andando a diminuire il numero di oggetti da
rappresentare per risparmiare calcoli in fase di rendering ed
aumentare le prestazioni;
4. Rendering: una volta letto, interpretato e convertito il modello urbano,
questo verrà renderizzato sul globo tridimensionale interattivo di WW,
con tanto di statistiche riguardanti le performance. Gli edifici
aumenteranno di livello di dettaglio col diminuire della loro distanza
dall'occhio della scena, rispettando i vari LOD del CityGML.
1.4 Struttura della tesi
Dopo un'introduzione alle tecnologie utilizzate si provvederà ad una
dettagliata descrizione delle quattro fasi sopracitate fornendo numerose
immagini a scopo illustrativo.
Sarà fornito dello pseudo-codice per spiegare i passi fondamentali e
saranno spiegate le principali tecniche di computer grafica utilizzate, come
ad esempio le BVH applicate al frustum culling.
Infine verranno mostrati alcuni possibili ulteriori sviluppi di questo tool ed
applicazioni come quelle menzionate all'inizio di questo capitolo per le
quali esso si rileverà di grande utilità.
2
2 Stato dell'arte
Per poter comprendere il funzionamento del tool (d'ora in poi chiamato
citygml4ww) presentato nel capitolo precedente, è necessaria un'introduzione
alle tecnologie utilizzate. In particolare verrà mostrato e spiegato l'encoding del
CityGML, per poi passare all'illustrazione del Nasa World Wind SDK e delle
librerie necessarie allo sviluppo di citygml4ww.
2.1 CityGML
2.1.1 GML
CityGML è un Application Schema per il GML (Geography Markup Language),
grammatica XML istituita e riconosciuta come standard internazionale dall'OGC
(Open Geospatial Consortium) per esprimere elementi geografici.
A differenza di altri GIS (Geographic Information System), GML è
object-oriented, facilitando così la modellazione semantica: sono presenti
gerarchie di aggregazione e di specializzazione (tassonomie, ovvero strutture
ad albero) nonché identificativi associati a ciascun oggetto che facilitano
associazioni o relazioni tra loro.
GML fornisce geometrie (ad esempio gml:Polygon) e coordinate (ad esempio
gml:pos) che insieme permettono di rappresentare oggetti geo-referenziati. Un
poligono (Polygon) può così essere rappresentato tramite un circuito
(LinearRing) di punti descritti da coordinate (pos) in un determinato sistema di
riferimento (srsName) nel seguente modo:
<gml:Polygon gml:id="poly1" srsName="urn:ogc:def:crs,crs:EPSG:4326">
<gml:exterior>
<gml:LinearRing>
<gml:pos> 46.0510 11.1313 211.874 </gml:pos>
<gml:pos> 46.0512 11.1309 212.637 </gml:pos>
............................................
<gml:pos> 46.0510 11.1313 211.874 </gml:pos>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
3
2 Stato dell'arte
2.1 CityGML
2.1.2 Struttura del CityGML
CityGML estende GML aggiungendo diverse aree tematiche, tra cui edifici,
strade, ponti, arredo urbano, vegetazione ecc.
Un file CityGML è caratterizzato da un modello urbano che, oltre ad alcuni
tag descrittivi, comprende all'interno del tag cityObjectMember uno o più
oggetti tra quelli sopracitati (descritti in seguito); la struttura base è la
seguente:
<?xmlversion="1.0" encoding="UTF-8"?>
<CityModel xmlns="http://www.citygml.org/citygml/1/0/0">
<gml:name>Cologne</gml:name>
<gml:boundedBy> <!-- bounding box della città -->
<gml:Envelope srsName="urn:ogc:def:crs,crs:EPSG:6.12:31466">
<gml:pos> 5659800.0 2561800.0 15.9 </gml:pos>
<gml:pos> 5662200.0 2564200.0 95.7 </gml:pos>
</gml:Envelope>
</gml:boundedBy>
<cityObjectMember> … </cityObjectMember>
........................................
<cityObjectMember> … </cityObjectMember>
</CityModel >
In questa tesi così come nell'implementazione di citygml4ww verranno
trattati soltanto gli edifici, mentre gli altri oggetti verranno tralasciati e
considerati in futuri sviluppi.
Gli edifici CityGML possono essere descritti in cinque diversi LOD (Level Of
Detail):
0) pianta dell'edificio
1) rappresentazione dell'edificio come un blocco
2) superfici tematiche (tetto, muro, pavimento), con texture
3) aggiunta di aperture (finestre, porte) ed i installazioni esterne
(balconi, …)
4) aggiunta di stanze e interni dell'edificio (arredamento, scale, …)
4
2 Stato dell'arte
2.1 CityGML
Nel seguente diagramma si possono notare le relazioni tra le varie
componenti dell'edificio e soprattutto il livello di dettaglio a partire dal
quale queste sono introdotte:
5
2 Stato dell'arte
2.1 CityGML
Un semplice edificio in LOD3, ad esempio, è descritto come segue:
<bldg:Building gml:id="building001">
<gml:boundedBy> <!-- bounding box dell'edificio -->
<gml:Envelope srsName="urn:ogc:def:crs,crs:EPSG:6.12:3068">
<gml:lowerCorner>3450014 5429996 0.0</gml:lowerCorner>
<gml:upperCorner>3450021 5430003 4.7</gml:upperCorner>
</gml:Envelope>
</gml:boundedBy>
<bldg:boundedBy>
<bldg:WallSurface gml:id="parete1">
<bldg:lod3MultiSurface>
<gml:MultiSurface>
.............................
<!-- lista di gml:Polygon -->
.............................
</gml:MultiSurface>
</bldg:lod3MultiSurface>
<bldg:opening>
<bldg:Door gml:id="wall1door">
<bldg:lod3MultiSurface>
.......................
</bldg:lod3MultiSurface>
</bldg:Door>
<bldg:Window gml:id="wall1window">
<bldg:lod3MultiSurface>
.......................
</bldg:lod3MultiSurface>
</bldg:Window>
<bldg:Window gml:id="w2"> … </bldg:Window>
<bldg:Window gml:id="w3"> … </bldg:Window>
</bldg:opening>
</bldg:WallSurface>
<bldg:WallSurface gml:id="parete2"> … </bldg:WallSurface>
<bldg:WallSurface gml:id="parete3"> … </bldg:WallSurface>
<bldg:WallSurface gml:id="parete4"> … </bldg:WallSurface>
6
2 Stato dell'arte
2.1 CityGML
<bldg:RoofSurface gml:id="tetto1"> … </bldg:RoofSurface>
<bldg:RoofSurface gml:id="tetto2"> … </bldg:RoofSurface>
<bldg:GroundSurface gml:id="pavim"> … </bldg:GroundSurface>
</bldg:boundedBy>
</bldg:Building>
Come si può notare, un edificio è definito come un insieme di pareti,
ognuna delle quali è descritta da una serie di poligoni e può contenere (a
partire dal LOD3) delle aperture (porte, finestre) anch'esse descritte da
una serie di poligoni. Dell'edificio fanno parte anche le componenti del
tetto e del pavimento. La descrizione delle superfici di tetto e pavimento è
analoga a quella delle pareti.
Un edificio descritto come sopra può apparire simile a quello nella
seguente immagine, dove viene anche mostrata la corrispondenza tra tag
e parti reali che costituiscono l'edificio:
2.1.3 Versione utilizzata
La versione di CityGML utilizzata è la 1.0.0 basata su GML3, in quanto la
2.0.0, rilasciata subito prima dell'inizio dello sviluppo di citygml4ww,
introduceva solo nuovi elementi che non sarebbero stati letti da
citygml4ww, come tunnel, ferrovie, superfici acquatiche eccetera, senza
cambiare la grammatica della versione 1.0.
7
2 Stato dell'arte
2.2 NASA World Wind
2.2 NASA World Wind
World Wind è un globo virtuale tridimensionale interattivo sviluppato dalla
Nasa che permette di esplorare la terra dallo spazio e di avvicinarsi al
terreno, ruotando ed inclinando il pianeta. La sua licenza open-source,
l'architettura API-centrica e l'utilizzo di Java come linguaggio di
programmazione fanno sì che World Wind sia uno strumento facilmente
ampliabile e multipiattaforma semplice da utilizzare.
2.2.1 SDK
Per lo sviluppo di applicazioni è disponibile l'SDK WWJ che utilizza la
libreria JOGL per implementare le chiamate di funzione a OpenGL, che
permettono di disegnare complesse scene tridimensionali a partire da
semplici primitive.
Siccome WWJ è un SDK non esiste una singola applicazione, anzi la API
propone centinaia di esempi che mostrano come sfruttare tutte le risorse
per qualsiasi scopo. Senza questi esempi verrebbe a meno la facilità d'uso
di questo potente strumento, dato che le sue più di 1000 classi si
estendono per oltre 615.000 righe di codice.
Utilizzando le librerie e le classi di WW si può ottenere il classico
programma base “Hello World” (fornito tra i file di esempio) con
pochissime istruzioni:
/* Copyright (C) 2001 United States Government as represented by the Administrator
of the National Aeronautics and Space Administration. All Rights Reserved. */
package gov.nasa.worldwindx.examples;
import gov.nasa.worldwind.*;
import gov.nasa.worldwind.awt.WorldWindowGLCanvas;
public class HelloWorldWind
{
private static class World extends javax.swing.JFrame
{
public World()
{
// il globo virtuale viene creato con proprietà standard
WorldWindowGLCanvas wwd = new WorldWindowGLCanvas();
8
2 Stato dell'arte
2.2 NASA World Wind
wwd.setPreferredSize(new java.awt.Dimension(1000, 800));
// viene impostato il livello del globo
wwd.setModel(new BasicModel());
// il globo viene inserito nel JFrame
this.getContentPane().add(wwd, java.awt.BorderLayout.CENTER);
this.pack();
}
}
public static void main(String[] args) {
// invokeLater esegue il codice in un thread AWT (convenzione di Swing)
java.awt.EventQueue.invokeLater(new Runnable() {
// viene creato un globo e reso visibile
public void run() { new Wordl().setVisible(true); }
} );
}
}
9
2 Stato dell'arte
2.2 NASA World Wind
2.2.2 GDAL
Per lo sviluppo di citygml4ww è stata utilizzata la libreria GDAL all'interno
di WWJ, nativamente inclusa nell'SDK. GDAL è una libreria rilasciata dalla
Open Source Geospatial Foundation per le trasformazioni di formati di dati
geo-spaziali. GDAL verrà utilizzata per convertire le coordinate dal sistema
di riferimento del file CityGML.
2.2.3 Versioni utilizzate
La versione di WWJ utilizzata è la 1.3.0, la più recente disponibile al
momento di inizio dello sviluppo, che include GDAL 1.7.2.
Per lo sviluppo di citygml4ww, WWJ è stato importato nel Java EE 6 IDE
(versione 1.4.2) di Eclipse (release Indigo, piattaforma 3.7), mostrato
nell'immagine seguente:
10
3 Implementazione
Nel capitolo 1.3 sono state accennate le quattro fasi in cui citygml4ww è
strutturato: lettura, parsing, ottimizzazione e rendering. In questo capitolo
ogni fase verrà spiegata nel dettaglio anche con l'ausilio di pseudo-codice e
screenshot e verranno illustrate le principali tecniche di computer grafica
utilizzate.
3.1 Lettura
La fase di lettura consiste, dato un file CityGML, nell'isolarne gli edifici che
saranno poi processati durante il parsing. Per gli scopi di citygml4ww verranno
infatti trattati soltanto gli edifici (fino al LOD3, senza quindi considerare gli
interni), mentre tutti gli altri elementi verranno ignorati; questa scelta
permette di non sprecare inutilmente CPU e memoria, aumentando così le
prestazioni del programma.
I file CityGML, basati sul linguaggio XML, sono documenti ben formati
rappresentabili tramite una struttura ad albero. In questa prima fase il dataset
in input viene convertito in albero DOM (Document Object Model, modello ad
oggetti del documento), lo standard ufficiale del W3C per la rappresentazione
di documenti strutturati. I nodi rappresentanti gli edifici, estratti dall'albero
tramite il tag ''bldg:Building'', vengono quindi salvati in una lista che verrà
poi letta nella fase di parsing.
Salvare gli edifici in una lista non è però sufficiente se si vuole rappresentarli
con le texture o i colori definiti nel CityGML: l'aspetto infatti non è salvato nel
nodo dell'edificio, ma in nodi appositi sia per le texture che per i colori. Ciò è
dovuto al fatto che una texture può essere utilizzata, con diverse coordinate,
per diversi poligoni (come ad esempio la foto di una parete di un edificio
quando la parete è divisa in tanti poligoni all'interno del CityGML); di
conseguenza invece che specificare texture e coordinate per ogni poligono
viene definita una sola volta ogni texture con le informazioni di quali poligoni la
utilizzeranno e con quali coordinate. Lo stesso vale per i colori: invece che
definire un nuovo colore per ogni poligono, si definisce ogni colore una volta
soltanto associando gli ID dei poligoni su cui il colore andrà applicato.
11
3 Implementazione
3.1 Lettura
Una texture è ad esempio descritta da
<app:ParameterizedTexture>
<app:imageURI>texture1.jpg</app:imageURI>
<app:target uri="#polygonA">
<app:TexCoordList>
<app:textureCoordinates>
0.0755862221122 0.249744519591
0.0755862221122 0.294397711754
0.0009967945516 0.294397711754
0.0755862221122 0.249744519591
</app:textureCoordinates>
</app:TexCoordList>
</app:target>
<app:target uri="#polygonB">
<app:TexCoordList>
<app:textureCoordinates>
0.0009967945516 0.294397711754
0.0009967945516 0.249744519591
0.0755862221122 0.249744519591
0.0009967945516 0.294397711754
</app:textureCoordinates>
</app:TexCoordList>
</app:target>
<app:target uri="#..."> ... </app:target>
<app:target uri="#..."> ... </app:target>
</app:ParameterizedTexture>
mentre un colore è definito da
<app:X3DMaterial>
<app:diffuseColor>0.588 0.587 0.588</app:diffuseColor>
<app:emissiveColor>0 0 0</app:emissiveColor>
<app:specularColor>1 1 1</app:specularColor>
<app:target>#polygon1</app:target>
<app:target>#polygon2</app:target>
<app:target>.........</app:target>
</app:X3DMaterial>
12
3 Implementazione
3.1 Lettura
Per poter applicare texture e colori ai poligoni in fase di parsing senza
dover ispezionare ogni volta l'albero alla ricerca dell'ID del poligono, anche
i nodi di texture e colori vengono salvati in due liste separate. Queste liste
vengono subito ispezionate ed ogni elemento processato come segue. Nel
caso delle texture, lo URI dell'immagine viene letto (e il percorso del file
viene reso assoluto aggiungendo in testa il percorso del file CityGML); per
ogni target viene estratto l'ID del poligono e le coordinate della texture;
queste informazioni vengono infine inserite in una hash table avente come
chiave l'ID del poligono target (per renderne immediato l'accesso) e come
valore un array contenente il percorso della texture e le coordinate. Un
procedimento analogo è effettuato per i colori, dove però nel campo valore
della hash table viene inserito il colore già processato con le sue varie
componenti.
Lo svantaggio di questo procedimento, che è il motivo per cui è stato
deprecato dopo la versione 0.4 di CityGML, è che si possono creare,
specialmente nel caso dei colori, moltissimi elementi uguali che si
differenziano soltanto per il target su cui vanno applicati. Sarebbe tuttavia
più costoso - in termini di operazioni da effettuare - ispezionare l'albero
DOM per ogni poligono (molto numerosi su grandi dataset) alla ricerca di
queste informazioni, che in molti casi non sono proprio presenti.
3.2 Parsing
La fase di parsing si occupa di trasformare tutti i nodi degli edifici salvati
durante la lettura in oggetti renderizzabili da WW. La classe di WW che
meglio si addice a rappresentare elementi del CityGML è la classe Polygon:
infatti ogni oggetto CityGML è definito da una serie di poligoni che lo
compongono. Per ogni nodo verranno quindi convertiti tutti i suoi poligoni;
questi poi verranno aggregati nella classe CityGMLBuilding creata
appositamente.
Ogni CityGMLBuilding contiene un edificio in cinque diversi livelli di
dettaglio che corrispondono approssimativamente a quelli del CityGML:
1. pianta (involucro convesso): corrisponde al LOD0
2. bounding box (estrusione della pianta alla massima altezza):
corrisponde al LOD1
13
3 Implementazione
3.2 Parsing
3. lista di poligoni con eventuali colori: corrisponde al LOD2 senza
texture
4. lista di poligoni con eventuali colori e texture: corrisponde al LOD2
5. lista di poligoni con eventuali colori e texture e aperture:
corrisponde al LOD3
Il diagramma di classe UML per CityGMLBuilding è il seguente:
CityGMLBuilding
centroid: Position
footprint: SurfacePolygon
bb: ExtrudedPolygon
lod1walls: ArrayList<MyPolygon>
lod2walls: ArrayList<MyPolygon>
lod3walls: ArrayList<MyPolygon>
CityGMLBuilding ( c: Position, ground: SurfacePolygon,
extr: ExtrudedPolygon, l1: ArrayList<MyPolygon>,
l2: ArrayList<MyPolygon>, l3: ArrayList<MyPolygon> )
3.2.1 Procedimento
Ogni nodo della lista prodotta in fase di lettura viene processato come
segue: in una nuova lista vengono estratti tutti i nodi discendenti da esso
aventi come tag ''gml:Polygon''; da ognuno di questi nodi vengono
estratte le coordinate, convertite dal CRS del dataset in latitudine e
longitudine, ed infine vengono creati tre Polygon con le coordinate
ottenute, uno per ciascuno degli ultimi tre livelli di dettaglio del
CityGMLBuilding.
Nelle hash table create durante la lettura viene cercato l'ID del poligono
CityGML e, se la chiave è presente, viene estratta la texture con le
coordinate e/o il colore. Al primo poligono è applicato il colore (o un colore
di default se non è specificato nessun colore), al secondo poligono viene
applicata la texture (o il colore del primo poligono se non ci sono texture),
mentre al terzo poligono oltre a texture e/o colore vengono applicati i
contorni interni nel caso il poligono abbia delle aperture (porte, finestre..).
Se due o tutti e tre i poligoni coincidono (nel caso in cui non siano
specificate texture e/o aperture) si fa sì che i poligoni coincidenti puntino
14
3 Implementazione
3.2 Parsing
alla stessa istanza, per occupare meno spazio in memoria. I tre poligoni
sono quindi inseriti in tre liste distinte.
Quando tutti i poligoni di un edificio sono stati creati anche le liste
vengono unite se due o tre interi livelli di dettaglio coincidono.
Durante la conversione delle coordinate di ogni poligono dell'edificio le
nuove coordinate vengono salvate anche in un Set; dopo aver convertito
tutti i poligoni viene calcolato a partire da tutti i punti salvati l'inviluppo
convesso dell'edificio e viene così creata la pianta. Dalle altezze dei vari
punti si ottiene l'altezza complessiva dell'edificio, usata per estrudere la
pianta e creare un pseudo bounding box. Infine viene calcolato il centroide
dell'edificio, approssimato come centro della pianta a metà altezza del
bounding box.
In conclusione viene istanziato un nuovo CityGMLBuilding con centroide,
pianta, bounding box e le tre liste contenenti i diversi LOD, e viene inserito
in un array che sarà poi letto in fase di ottimizzazione una volta che il
parsing di tutti gli edifici sarà stato completato.
Ecco come appare un edificio in WW al termine del parsing nei vari LOD:
Pianta
Bounding Box:
15
3 Implementazione
3.2 Parsing
Livello 1:
Livello 2:
16
3 Implementazione
3.2 Parsing
Livello 3:
Si può notare come il bounding box sia effettivamente l'estrusione della
pianta. Il livello 1 invece sembra “scolpito” nel bounding box; i colori delle
pareti e del tetto sono quelli assegnati di default, mentre quelli delle tende
al piano terra erano specificati e sono stati quindi estratti dalla hash map.
Nel livello 2 sono state aggiunte le texture, anch'esse prima salvate e poi
estratte dalla hash map (anche il colore apparentemente uniforme delle
pareti è in realtà una texture). Nel livello 3 sono state infine aggiunte le
finestre e la porta, anch'esse con i loro colori o le loro texture.
17
3 Implementazione
3.2 Parsing
3.2.2 Extra feature
La funzione di parsing include anche un'opzione per poter moltiplicare un
dataset un numero arbitrario di volte con un certo offset da quello
originale; le copie del dataset saranno disposte intorno all'originale, che
quindi risulterà in posizione centrale.
Questa funzione risulta molto utile nello studio delle performance perché
permette di simulare città enormi che non sono ancora disponibili ma che
potrebbe essere necessario rappresentare in futuro.
Esempio di un edificio moltiplicato 5x7 volte con un offset di 0.0002° in
latitudine e 0.0003° in longitudine (all'edificio originale non sono state
applicate texture per evidenziare il fatto che le copie sono costruite
intorno ad esso centrandolo):
3.3 Ottimizzazione
La fase di ottimizzazione si occupa di creare delle strutture dati che
contengano gli edifici e che alleggeriscano successivamente il rendering.
L'ottimizzazione sfrutta il concetto delle BVH, strutture ad albero ricavate
da insiemi di oggetti geometrici: essi vengono racchiusi da bounding
18
3 Implementazione
3.3 Ottimizzazione
volumes che formano i nodi foglia dell'albero. Questi nodi sono poi
raggruppati in piccoli insiemi che nella struttura ad albero rappresentano il
padre e così ricorsivamente fino ad arrivare alla radice dell'albero.
Le BVH sono poi utilizzate nella collision detection: partendo dalla radice,
se un nodo non è visibile nella scena da renderizzare allora neanche i suoi
figli (e procedendo ricorsivamente fino alle foglie neanche gli oggetti
geometrici in esso contenuti) saranno visibili, quindi viene effettuato
immediatamente un pruning del ramo dalla lista di oggetti da
renderizzare. Se invece il nodo è visibile si va in ricorsione sui figli, perché
alcune parti potrebbero essere fuori dalla scena; se si arriva agli oggetti
geometrici senza pruning questi vengono renderizzati.
L'overhead computazionale introdotto viene ripagato durante il rendering
nel caso in cui una parte della scena non sia visibile: la complessità può
essere logaritmica rispetto al numero di oggetti.
3.3.1 Procedimento
La città viene divisa in “quartieri” a seconda della sua ampiezza; la
dimensione approssimativa dei quartieri è fissata a un centesimo di grado
in longitudine e mezzo centesimo di grado in latitudine, in modo da
dividere il mondo nello stesso numero di parti (18000) in latitudine e
longitudine e non dover dividere ogni dataset nello stesso numero di
blocchi. La dimensione effettiva dei quartieri è approssimativa perché in
base alle dimensioni specificate viene calcolato quanti ne sono necessari in
latitudine e longitudine ed infine la città viene divisa in quartieri regolari in
19
3 Implementazione
3.3 Ottimizzazione
base alle sue dimensioni.
Ogni quartiere è diviso in due sia in latitudine che in longitudine, e
contiene perciò quattro “isolati”. L'array di CityGMLBuilding creato durante
il parsing viene quindi ispezionato e ogni edificio viene inserito nell'isolato
corretto del quartiere corretto a seconda della posizione del suo centroide
rispetto agli estremi della città.
Per ogni quartiere poi viene calcolato l'inviluppo convesso di ogni isolato a
partire dai punti delle piante degli edifici che esso contiene e l'inviluppo
dell'intero quartiere a partire da quelli dei suoi quattro isolati.
Tutti i quartieri vengono infine inseriti in un RenderabeLayer che li
renderizzerà al termine del preprocessing.
La struttura gerarchica di quartieri, isolati ed edifici si può notare
nell'immagine seguente: gli edifici sono racchiusi dagli isolati (in alcuni
punti sovrapposti) che a loro volta sono racchiusi nel quartiere.
20
3 Implementazione
3.3 Ottimizzazione
3.3.2 Calcolo dell'inviluppo convesso
In questo paragrafo viene descritto l'algoritmo della catena monotona
utilizzato per calcolare l'inviluppo complesso di un insieme di punti sia
nella fase di parsing ma soprattutto per la creazione dell'involucro di
quartieri e isolati.
I punti in input sono in 2D, poiché gli inviluppi ottenuti saranno proiettati
sul terreno; essi sono salvati in un SortedSet per evitare di calcolare
duplicati (quando differiscono solo per l'altezza) e perché l'algoritmo
necessita che i punti siano ordinati lessicograficamente a seconda
dell'ascissa (e in caso di uguaglianza a seconda dell'ordinata).
L'algoritmo si divide in due parti: si cerca la catena monotona tra i due
estremi sull'ascissa utilizzando il metodo di Graham prima nella parte
inferiore e poi in quella superiore.
Il lato inferiore dell'inviluppo si ottiene
partendo dal punto con ascissa
minore; iterando sull'insieme in input
si cercano i punti che facciano una
“svolta” in senso antiorario e si
aggiungono all'insieme di output fino
ad arrivare al punto con ascissa
massima. Il lato superiore si trova con
lo stesso procedimento ma scorrendo
l'insieme in ordine inverso.
In pseudo-codice:
INPUT: List P of 2D points sorted by x-coordinate (in case of
a tie, by y-coordinate)
U, L = new List()
// upper and lower part respectively
for i = 0, 1, ..., P.length-1
while (L contains at least two points AND the sequence of
last two points of L and the point P[i] does not
make a counter-clockwise turn)
21
3 Implementazione
3.3 Ottimizzazione
remove the last point from L
append P[i] to L
for i = P.length-1, P.length-2, ..., 0
while (U contains at least two points AND the sequence of
last two points of U and the point P[i] does not
make a counter-clockwise turn)
remove the last point from U
append P[i] to U
Remove the last point of each list (it's the same as the first
point of the other list)
return (concatenate(L,U))
Avendo l'input già ordinato la complessità dell'algoritmo è O(n).
3.4 Rendering
Dopo aver letto, trasformato e ottimizzato il dataset CityGML in input, lo si
può visualizzare sul globo virtuale. Viene quindi creata un'istanza della
classe AppFrame di WW, alla quale viene passato il RenderableLayer
creato in fase di ottimizzazione. Questo layer contiene tutte le CityTile (i
“quartieri”), sulle quali viene chiamato in automatico il metodo render ogni
volta che la scena cambia (ovvero quando avvengono zoom o
spostamenti).
Le CityTile sono renderizzate con diverso livello di dettaglio a seconda
della loro distanza dall'occhio della vista; quando il metodo render viene
chiamato, viene calcolata la distanza dal suo centro. Se questa distanza è
oltre una soglia massima, viene renderizzato solo l'inviluppo del quartiere,
altrimenti per ogni isolato viene calcolata la sua distanza dall'occhio della
scena: se questa distanza è superiore ad un'altra soglia, allora viene
renderizzato l'inviluppo dell'isolato, altrimenti vengono renderizzati tutti gli
edifici in esso contenuti. In quest'ultimo caso anche per ogni edificio viene
calcolata la distanza dal suo centroide alla camera, e in base a questa
viene renderizzato uno dei cinque livelli di dettaglio.
22
3 Implementazione
3.4 Rendering
Distanza molto grande: viene renderizzato solo l'inviluppo della CityTile.
Distanza minore: si distinguono i quattro isolati.
23
3 Implementazione
3.4 Rendering
Lieve avvicinamento: vengono renderizzate le
piante degli edifici dei due isolati più vicini.
Ulteriore avvicinamento: vengono renderizzate le piante
anche degli altri due isolati, e le BB dei primi edifici.
24
3 Implementazione
3.4 Rendering
Diminuzione della distanza: gli edifici più vicini
sono renderizzati con LOD1, gli altri con la BB.
Questa particolare implementazione del rendering sfrutta le gerarchie
create durante l'ottimizzazione per risparmiare calcoli quando non è
necessario: infatti se viene renderizzato solo l'inviluppo del quartiere è
inutile calcolare la distanza di ogni singolo edificio.
La tecnica che maggiormente utilizza le gerarchie per risparmiare ulteriori
calcoli e velocizzare quindi il rendering è però il frustum culling.
Il viewing frustum è la regione di spazio che rappresenta il campo visivo
della camera virtuale; la sua forma è quella di tronco (frustum) di
piramide a base rettangolare al cui vertice è posizionata la camera. Viene
utilizzato un tronco di piramide perché il campo visivo non inizia dal
vertice ma da un near plane fissato; la distanza massima visibile è data
invece dal far plane.
25
3 Implementazione
3.4 Rendering
Il frustum culling consiste nel calcolare se
un oggetto si trova all'interno del view
frustum per stabilire se vada renderizzato
oppure no: se è fuori dal campo visivo
della camera si possono risparmiare draw
call che non avrebbero nessun effetto
sull'immagine di output. Naturalmente il
frustum culling è più efficiente se applicato
ad una gerarchia: infatti se un bounding
volume non si trova nel frustum, non sarà
necessario eseguire il test sugli oggetti in
esso contenuti così come non sarà
necessario renderizzarli.
La fase di rendering è dunque alleggerita da frustum culling e dal
clustering degli edifici per evitare, specialmente in grandi dataset, di dover
effettuare una draw call per ogni singolo poligono letto nel dataset.
Citygml4ww è provvisto di un pannello in cui ad ogni frame vengono
aggiornate delle statistiche sul numero effettivo di poligoni renderizzati e
sul numero di edifici visibili. Su dataset molto grandi si possono ottenere
risultati come questi:
26
3 Implementazione
3.4 Rendering
In questo esempio solo il 2% dei quasi 300.000 poligoni è stato
renderizzato, riducendo di 50 volte il numero di draw call necessarie a
renderizzare la scena ed aumentando quindi considerevolmente il frame
rate.
3.5 Simulatore di dinamica dei fluidi
Come esempio delle possibili applicazioni di citygml4ww, il prototipo
realizzato include un'opzione per esportare un'area rettangolare della città
in un file javascript che poi verrà utilizzato in un simulatore della
propagazione di fluidi dove gli edifici saranno gli ostacoli che lo
devieranno.
Un bottone nella finestra permette di selezionare sulla superficie del globo
un'area rettangolare allineata agli assi; la dimensione del settore può
sempre essere modificata e il settore può essere spostato. Quando il
bottone viene premuto, per tutti gli edifici visibili viene renderizzata la
pianta indipendentemente dalla distanza, perché è necessario avere
un'anteprima di come apparirà la simulazione (viene renderizzata la pianta
perché il simulatore è in 2D).
Una volta creato il settore, il bottone cambia stato e, se cliccato
nuovamente converte le coordinate di tutti gli edifici parzialmente o
totalmente all'interno del settore (dopo aver fatto del pruning sulle BVH)
27
3 Implementazione
3.5 Simulatore di dinamica dei fluidi
in pixel coordinates e aggiorna una stringa che tiene conto della sintassi
javascript rappresentando ogni edificio come un array di coordinate intere
(x,y). Nel simulatore esterno le coordinate sono comprese nel range
[0-99] su entrambi gli assi; se il settore selezionato non è quadrato ma
rettangolare esso verrà centrato orizzontalmente se l'aspect ratio è minore
di 1 oppure allineato al lato superiore in caso contrario (ovvero le pixel
coordinates risultanti per l'asse y andranno da 0 a 99/aspectRatio).
Dopo aver salvato le coordinate il bottone cambia nuovamente stato
permettendo di uscire dalla modalità di selezione dell'area per la
simulazione e tornare alla visualizzazione normale.
Aprendo il file html del simulatore viene chiamato il file javascript
esportato da WW; le coordinate vengono quindi interpretate e gli edifici
disegnati e riconosciuti come ostacoli per la dispersione di fluidi; la
simulazione può ora avere inizio:
28
3 Implementazione
3.5 Simulatore di dinamica dei fluidi
3.5.1 Clipping
Se un edificio si trova completamente all'interno del settore le sue
coordinate vengono normalizzate nell'intervallo dato dall'aspect ratio del
settore. In caso contrario bisogna effettuare il clipping sul poligono,
ovvero determinare la porzione del poligono che si trova all'interno del
settore, affinché non vi siano poligoni con coordinate al di fuori del range
previsto; senza clipping infatti verrebbero disegnate e riconosciute come
ostacoli parti di edifici non comprese nel settore selezionato su WW.
L'algoritmo di Sutherland-Hodgman è un ottimo algoritmo per il clipping di
poligoni: considerando un lato per volta dell'area di clipping, esso estende
tale lato all'infinito, dopodiché crea un nuovo poligono iterando su ogni
lato (due punti consecutivi) del poligono precedentemente processato
agendo come segue:
• se il lato è interno all'area di clipping rispetto al lato di clipping
considerato, il secondo punto viene aggiunto al nuovo poligono;
• se il lato interseca il lato di clipping, l'intersezione viene aggiunta al
nuovo poligono e se dei due punti è il secondo ad essere interno
all'area, anch'esso viene aggiunto al nuovo poligono;
dopo aver effettuato il clipping su un lato dell'area, il poligono iniziale
viene sostituito col nuovo poligono e viene effettuato il clipping sui
rimanenti lati dell'area.
Esempio di clipping su un lato:
Input: poligono P1P2P3P4
Nuovo poligono:
– P1P2 → nessun punto
– P2P3 → S1 e P3
– P3P4 → P4
– P4P1 → S2
Il lato S1S2 chiude il poligono.
Output: poligono S1P3P4S2
29
3 Implementazione
3.5 Simulatore di dinamica dei fluidi
Il clipping di un poligono su un'intera regione è realizzato tramite il
clipping del poligono su ogni lato della regione:
In pseudo-codice:
INPUT: Polygon polygon
Polygon clipped
for each clipEdge do
clipped.clear()
for i = 0, 1, ..., polygon.length-1
Pi
= polygon.vertex[i]
Pi+1 = polygon.vertex[i+1]
if (Pi is inside clipping region)
if (Pi+1 is inside clipping region)
clipped.add(Pi+1)
else clipped.add(intersect(Pi, Pi+1, clipEdge)
else
if (Pi+1 is inside clipping region)
clipped.add(intersect(Pi, Pi+1, clipEdge)
clipped.add(Pi+1)
polygon = clipped
return clipped
30
4 Problemi e limiti
Durante lo sviluppo di citygml4ww sono stati incontrati alcuni problemi ai quali
non è stata trovata soluzione, specialmente per quanto riguarda la gestione del
CityGML. Questo capitolo ha lo scopo di descriverli, motivandone la mancata
risoluzione e spiegando come il problema sia stato aggirato o come sarebbe
possibile risolvere.
4.1 Coordinate Reference System
Nonostante il CityGML sia provvisto di un apposito tag per indicare il sistema di
riferimento usato per descrivere le coordinate, nella maggior parte dei dataset
disponibili in rete (tra cui quelli sul sito ufficiale di CityGML) esso è errato o
addirittura non presente; in altri dataset invece è specificato solo una volta, in
altri per ogni poligono. La mancanza di uno standard unico per definire il
sistema di coordinate rende impossibile determinarlo in maniera
automatizzata; perciò è stato necessario tenere memorizzati tutti i dataset a
disposizione ed il loro relativo SRS trovato in maniera empirica. A causa di ciò
è inoltre poco pratico aprire una finestra all'avvio del programma per far
caricare all'utente il dataset che desidera visualizzare, perché bisognerebbe
quantomeno confrontare il nome del file e tenere salvate nel programma le
associazioni file → EPSG, e ovviamente questo procedimento non è immune da
eventuali rinominazioni dei file.
4.2 Document Object Model
L'approccio DOM per la lettura del dataset è efficiente grazie alla sua struttura
ad albero veloce da attraversare, ma ha lo svantaggio di dover salvare tutti i
nodi in memoria: per dataset molto grandi la memoria disponibile può non
essere sufficiente; in alcuni casi la heap di 1GB allocata di default dalla JVM di
Eclipse non è stata sufficiente e si è dovuto aumentarla modificando gli
argomenti per la compilazione. Questa soluzione però, oltre ad essere limitata
dalla dimensione della RAM del computer in uso (e quindi non risolve il
problema alla radice) e a precludere molta più memoria agli altri processi, poco
31
4 Problemi e limiti
4.2 Document Object Model
si addice ad un eventuale utilizzo futuro dell'applicazione su sistemi mobili.
Analizzando un modello completo composto da cinque edifici in LOD3 con
textures si è visto che la lista contenente i nodi con gli edifici occupa circa
33MB in memoria, mentre il RenderableLayer contenente gli edifici
convertiti ne occupa soltanto 15. Leggendo e processando un nodo alla
volta invece che prima salvarli tutti consentirebbe quindi di utilizzare circa
1/3 della heap (la lista dei nodi non può essere cancellata fino alla fine del
parsing, ed essendo grande più o meno il doppio della lista di
CityGMLBuilding rappresenta i due terzi della memoria in uso); la memoria
utilizzata può scendere fino a circa il 10% nel caso in cui i tre livelli di
dettaglio coincidano, non avendo così texture e colori da salvare e potendo
“fondere” le tre liste dei vari livelli di dettaglio per ogni edificio.
Un risparmio di memoria di questo genere permetterebbe di rappresentare
dataset molto più grandi o di portare l'applicazione anche su dispositivi
mobili, di lasciare più memoria agli altri programmi in uso e di evitare che
la heap sia presto piena e necessiti di numerose e costose chiamate al
garbage collector, riducendo quindi anche i tempi di processing.
Un approccio alternativo per risolvere l'enorme utilizzo di memoria
sarebbe il parsing SAX, una API basata sugli eventi che legge il file in
maniera sequenziale e riporta gli eventi man mano che succedono, senza
salvarli in memoria. Normalmente l'accesso sequenziale è il motivo che
costringe ad utilizzare il DOM invece del SAX; in questo caso invece la
limitazione del SAX è data dal fatto che non genera nodi, ma eventi,
rendendo l'ispezione impossibile in fase di parsing.
4.3 CityGML
Il CityGML può racchiudere potenzialmente un'enorme numero di
informazioni riguardanti ogni elemento; molte volte però accade che un
dataset venga creato con le sole informazioni necessarie allo scopo per cui
è destinato. L'eterogeneità della struttura dei vari dataset disponibili ha
reso necessaria la scrittura di un parser generale che si adatti ad ogni
modello e che possa gestire la mancanza di alcuni nodi che in WW
sarebbero di grande utilità.
Un esempio è dato dalla pianta degli edifici: il CityGML prevede il nodo
''bldg:GroundSurface'' nel quale è specificata la pianta. Se questo nodo
32
4 Problemi e limiti
4.3 CityGML
fosse presente in ogni edificio di ogni dataset non bisognerebbe calcolare
l'inviluppo convesso degli edifici per avere la pianta, e si avrebbe una
forma sicuramente più accurata quando l'edificio viene rappresentato in
questo livello di dettaglio. Tuttavia questa informazione non solo in alcuni
dataset è completamente assente, ma anche all'interno dello stesso
modello può essere presente in alcuni edifici soltanto.
In altri casi invece le strutture non rispettano lo standard: ad esempio ci
sono pareti verticali definite come pianta dell'edificio, edifici che pur
essendo separati sono racchiusi all'interno dello stesso ''bldg:Building'',
oppure edifici che pur usando il tag ''bldg:opening'' per definire ad
esempio una finestra su un muro hanno quella parete già con il buco
anche nei livelli di dettaglio inferiori, dovendo così tassellare la parete con
un maggior numero di poligoni, che come conseguenza ha un maggior
numero di draw call da chiamare inutilmente per ogni frame. Queste però
sono soltanto delle eccezioni, e non sono state gestite nel programma in
quanto non riferite ad un documento CityGML ben formato.
Altri dataset sono creati invece con dei tool che rappresentano una
superficie piana come una parete con diversi poligoni o un grande numero
di triangoli: anche in questo caso le performance risultano notevolmente
ridotte, ma unire poligoni complanari oltre ad essere di per sé complicato
risulta ingestibile quando si hanno delle texture con le rispettive
coordinate per ogni poligono.
4.4 World Wind
Alcuni problemi, seppur di minor rilievo, sono stati riscontrati anche in
WW: per esempio i poligoni che contengono dei buchi devono essere
tassellati in quanto OpenGL gestisce solo poligoni convessi; il
tassellamento automatico di un poligono su cui è applicata una texture
però non ricalcola le coordinate della texture, così questa non verrà
visualizzata correttamente. Un altro problema dato dalle texture è che in
alcuni dataset le coordinate della texture sono date in un ordine diverso da
quelle del poligono, e la conseguenza è che le texture vengono ruotate di
±90° o 180°, causando l'effetto contrario che dovrebbe dare una texture,
ovvero rendere un oggetto ancora più simile alla realtà.
La classe Polygon di WW usa di default le texture fisse, e non ripetute. Per
33
4 Problemi e limiti
4.4 World Wind
poter abilitare l'utilizzo di texture ripetute si è creata una nuova classe che
estende Polygon su cui viene fato un override del metodo makeTexture in
modo che chiami una nuova classe che estende LazilyLoadedTexture in cui
nel metodo setTextureParameters vengono modificate le chiamate a
OpenGL in modo da abilitare le texture ripetute. Si è scelto di procedere in
questo modo perché modificare semplicemente il codice di WW non
avrebbe permesso di visualizzare le texture ripetute su altri dispositivi
senza prima modificare le classi di WW.
Un ultimo problema riscontrato con WW riguarda la mancanza di DEM
dettagliati per i vari luoghi dove sono presenti dei dataset: il risultato è
che in alcuni dataset gli edifici sono sospesi a mezz'aria, mentre in altri
sono sommersi nel terreno per qualche metro o addirittura
completamente. Per il modello di Trento, il più importante per gli scopi di
citygml4ww, sono state installate delle altitudini precise e questo
problema è stato completamente risolto.
34
5 Sviluppi futuri
5.1 Miglioramenti possibili
Siccome la maggior parte dei problemi elencati nel capitolo precedente
derivano dal CityGML o da World Wind, per risolverlo bisognerebbe fare una
proposta di revisione dello standard CityGML all'OGC in modo che definiscano
delle regole fisse per costruire un dataset senza avere tanti diversi modi per
definire lo stesso oggetto o dei nodi importanti definiti solo in alcuni edifici,
come ad esempio la pianta dell'edificio, ed una richiesta agli sviluppatori di WW
per un miglioramento della gestione delle texture, oppure tentare di migliorarle
autonomamente.
5.1.1 Memoria necessaria
Per quanto riguarda il problema dell'eccessivo utilizzo di memoria si può
sfruttare la divisione in tile di alcuni dataset: certi grandi modelli urbani infatti
sono salvati su più file CityGML, ognuno dei quali contiene una parte della città.
Caricando e facendo il parsing di un file alla volta si riduce l'utilizzo di memoria
per salvare i nodi del documento, in quanto al termine del parsing di ogni file i
suoi nodi possono essere cancellati. Anche se il risparmio di memoria non è
paragonabile all'approccio teorico di considerare un edificio alla volta, i risultati
sarebbero comunque apprezzabili.
5.1.2 Simulazione della dispersione di fluidi
Un possibile miglioramento riguarda anche l'esempio della dispersione di fluidi:
invece che esportare gli edifici per poi utilizzarli nella simulazione
bidimensionale, si può importare il simulatore all'interno di WW ed estenderlo
nelle tre dimensioni: si avrebbe così una simulazione più chiara e interattiva e
si potrebbero analizzare gli effetti della dispersione di fluidi da diversi punti di
vista e con diverse angolazioni. La contestualizzazione della simulazione la
renderebbe certamente molto più efficace.
35
5 Sviluppi futuri
5.1 Miglioramenti possibili
5.1.3 Aggregazione degli edifici
L'implementazione che sarà maggiormente necessaria è però una migliore
aggregazione degli edifici: al momento infatti un isolato alla latitudine di
Trento ha un'area di circa 0.6 km2, e un quartiere è perciò grande quasi
2,5 km2. Oltre alle grandezze poco fedeli alla realtà, anche la forma non
tiene conto della reale disposizione degli edifici, ma segue semplicemente
una griglia regolare. Avendo a disposizione un grafo stradale si potrebbero
aggregare edifici racchiusi da piccole strade in isolati, isolati racchiusi da
strade secondarie in zone, zone racchiuse da strade principali in quartieri e
via così, anche su un maggior numero di livelli di dettaglio. Questa
suddivisione non solo permetterebbe un passaggio più graduale dalla
visualizzazione di un'ampia zona alla visualizzazione delle piante di tutti gli
edifici contenuti nella zona stessa, ma fornirebbe anche delle gerarchie
migliori nei vari casi in cui viene effettuata la collision detection,
risparmiando un maggior numero di calcoli in molti casi.
5.2 Utilizzi del programma
Citygml4ww
verrà
utilizzato
nell'ambito
del
progetto
i-Scope
(Interoperable Smart City services through an Open Platform for urban
Ecosystems) coordinato dalla Fondazione Graphitech, presso la quale è
stata svolta questa tesi, in collaborazione con altri partner italiani ed
europei: la disposizione e l'ingombro degli edifici contestualizzati in un
ambiente tridimensionale sarà d'aiuto nello studio della mobilità di
persone anziane o disabili, nello studio della potenziale installazione di
pannelli solari e nello studio dell'inquinamento acustico o nella sua
simulazione.
La simulazione della dispersione dei fluidi è parte del progetto GEPSUS
(Geographical Information Processing for Environmental Pollution-Related
Security within Urban Scale Environments) in cui la Fondazione Graphitech
collabora con partner internazionali e che vede il Ministero della Difesa del
Montenegro come utente finale. L'esportazione di aree di modelli urbani
CityGML o l'eventuale futura importazione del simulatore all'interno di WW
certamente arricchiscono questo strumento permettendo degli studi più
precisi ed accurati.
36
6 Conclusioni
In questa tesi è stata mostrata un'applicazione che legge, analizza e converte
modelli urbani CityGML e li contestualizza nel globo virtuale fornito da World
Wind. Per le scelte implementative spiegate in precedenza sono stati
considerati solo gli edifici e non gli altri elementi rappresentabili dal CityGML e
soltanto fino al terzo livello di dettaglio.
L'enorme numero di poligoni con cui un'intera città deve essere descritta ha
spinto inoltre ad ottimizzare la visualizzazione, creando delle gerarchie di
volumi per renderizzare aggregazioni di edifici quando i singoli elementi
risultano indistinguibili e rappresentando gli edifici con diversi livelli di dettaglio
a seconda della loro distanza.
La funzione per la moltiplicazione dei dataset ha inoltre permesso di simulare
delle metropoli per testare l'utilizzo di memoria e CPU: in questi casi è emersa
la necessità di migliorare la gestione della memoria. Sono così state migliorate
le strutture dati necessarie e, oltre a referenziare la stessa lista di poligoni in
caso più livelli di dettaglio di un edificio coincidano, è stato applicato lo stesso
procedimento ai singoli poligoni, utile nel caso i livelli di dettaglio non
coincidano completamente.
In definitiva quindi citygml4ww è il primo strumento che contestualizza gli
edifici di un modello CityGML in un ambiente tridimensionale esteso a tutto il
mondo e ne ottimizza la visualizzazione per ridurre le risorse richieste ed
aumentare le performance del rendering.
37
7 Ringraziamenti
C'è un grande numero di persone che devo ringraziare per essere arrivato fin
qui, e per non fare torti a nessuno seguirò un ordine meramente cronologico.
Prima di tutto grazie ai miei amici nonché compagni di corso Loris, Alessandro,
Gustavo, Giulia, Gabriele, Lorenzo, Martino, Stefano, Matej, con i quali ho
realizzato progetti per l'università, studiato per gli esami e condiviso numerosi
momenti di allegria in questi tre anni.
Un secondo ringraziamento va all'Università degli Studi di Trento - e in
particolare all'Ufficio LLP Erasmus e all'ufficio Erasmus della Facoltà di Scienze
Matematiche Fisiche e Naturali – e al Karlsruher Institut für Technologie perché
il semestre che ho trascorso in questa università tedesca non solo mi ha
arricchito di tantissime nuove esperienze facendomi confrontare con diverse
realtà, ma soprattutto il corso di computer grafica offerto dal KIT ha illuminato
una strada importante per il mio futuro da informatico in quanto mette in
pratica i miei studi in una mia grande passione.
Infine un ringraziamento speciale va al mio relatore prof. Nicola Conci, al
correlatore Raffaele De Amicis per avermi proposto una tesi così interessante e
per il supporto fornito in seguito, e a tutto lo staff della Fondazione Graphitech
per la disponibilità e la cordialità dimostrate nei miei confronti, in particolare
grazie al mio correlatore Daniele per il supporto tecnico fornito soprattutto
nella fase iniziale e a Marco per il testing ed i suggerimenti che hanno
aumentato la qualità del programma.
39
8 Appendici
8.1 Acronimi
API
Application Programming Interface
BVH
Bounding Volume Hierarchy
CRS
Coordinate Reference System
DEM
Digital Elevation Model
DOM
Document Object Model
EPSG
European Petroleum Survey Group
GDAL
Geospatial Data Abstraction Library
GIS
Geographic Information System
GML
Geography Markup Language
IDE
Integrated Development Environment
JOGL
Java OpenGL
JVM
Java Virtual Machine
LOD
Level Of Detail
NASA
National Aeronautics and Space Administration
OGC
Open Geospatial Consortium
OpenGL
Open Graphics Library
SAX
Simple API for XML
SDK
Software Development Kit
SRS
Spatial Reference System
UIM
Urban Information Model
UML
Unified Modeling Language
URI
Uniform Resource Identifier
W3C
World Wide Web Consortium
WW
World Wind
WWJ
World Wind for Java
XML
eXtensible Markup Language
41
8 Appendici
8.2 Bibliografia
8.2 Bibliografia
●
●
●
●
●
●
●
●
●
●
●
●
http://www.citygml.org/index.php?id=1523
http://www.iscopeproject.net/iscopeNew/index.php?
option=com_content&view=article&id=55&Itemid=53
http://www.citygml.org/fileadmin/citygml/docs/CityGML_Tutorial_K
olbe_Internet.pdf
http://en.wikipedia.org/wiki/Geography_Markup_Language
http://goworldwind.org/about/
http://en.wikipedia.org/wiki/NASA_World_Wind
https://www.ohloh.net/p/wwj/analyses/latest/languages_summary
http://it.wikipedia.org/wiki/Document_Object_Model
http://en.wikipedia.org/wiki/Bounding_volume_hierarchy
http://en.wikibooks.org/wiki/Algorithm_Implementation/Geometry/
Convex_hull/Monotone_chain
http://www.sunshine2k.de/stuff/Java/SutherlandHodgman/Sutherla
ndHodgman.html
http://en.wikipedia.org/wiki/Simple_API_for_XML
8.3 Immagini
●
●
●
●
●
●
●
http://ars.els-cdn.com/content/image/1-s2.0S0924271612000779-gr3.jpg
http://www.geores.de/resourcesHomepage/lod3Build.png
http://cg.ibds.kit.edu/lehre/ws2011/cg/downloads/internal/05_Rae
umlicheDatenstrukturen.pdf
http://upload.wikimedia.org/wikipedia/commons/d/d5/UpperAndLo
werConvexHulls.png
http://techpubs.sgi.com/library/dynaweb_docs/0620/SGI_Develope
r/books/Optimizer_PG/sgi_html/figures/view.frustum.culling.gif
http://cg.ibds.kit.edu/lehre/ws2011/cg/downloads/internal/06_Rast
erisierung_Teil1.pdf
http://onlinemca.com/mca_course/kurukshetra_university/semeste
r5/computergraphics/img_computer_graphics/sutherland_hodgman
1.bmp
42