WebGL basierte visuelle Analyse von 3D Geomodellen

Transkript

1 Technische Universität Bergakademie Freiberg Fakultät für Geologie, Geotechnik und Bergbau Institut für Geophysik und Geoinformatik Lehrstuhl für mathematische Geologie und Geoinformatik Masterarbeit WebGL basierte visuelle Analyse von 3D Geomodellen Paul Gabriel Master Geoinformatik Matrikel: Betreuer/1. Korrektor: Prof. Dr. Helmut Schaeben 2. Korrektor: Prof. Dr. Bernhard Jung

2 Eidesstattliche Erklärung Ich versichere, dass ich diese Arbeit selbständig verfasst und keine anderen Hilfsmittel als die angegebenen benutzt habe. Die Stellen der Arbeit, die anderen Werken dem Wortlaut oder dem Sinn nach entnommen sind, habe ich in jedem einzelnen Fall unter Angabe der Quelle als Entlehnung kenntlich gemacht. Diese Versicherung bezieht sich auch auf die bildlichen Darstellungen Paul Gabriel

3 I Zusammenfassung Durch die kontinuierliche Weiterentwicklung der Browser und Webtechnologien ist es mittlerweile möglich dreidimensionale Grafiken in Browsern zu betrachten, ohne dass zusätzliche Plugins installiert werden müssen. Dies ermöglicht es fachspezifische Modelle ohne spezielle Modellierungssoftware, wie beispielsweise CAD Systemen, ansehen zu können. Dies können zum Beispiel komplexe geologische Modelle sein, die der Bevölkerung oder der Industrie bereitgestellt werden. Gleichzeitig wurde im Rahmen des EU Projekts Promine an der TU Bergakademie Freiberg ein Datenmodell zur Speicherung von dreidimensionalen Geodaten in einer Datenbank entwickelt. Ein Ziel dabei ist es, dass die gespeicherten Modelle mit Eigenschaften versehen werden können. Diese Eigenschaften können, neben ihrer Funktion eine Parameterverteilung im Raum zu definieren, auch zur Abfrage und Analyse des gespeicherten Modells dienen. Bisher können die Daten aus dieser Datenbank nur mit einer speziellen Clientsoftware dargestellt und abgefragt werden. Durch eine internetbasierte Anwendung können die beiden Ansätze miteinander kombiniert werden, sodass sich beispielsweise jeder interessierte Nutzer Daten beschaffen kann. Ziel dieser Arbeit ist es, eine solche Anwendung auf Basis von WebGL und sogenannten Web 2.0 Funktionen zu erstellen.

4 Inhaltsverzeichnis II Inhaltsverzeichnis Abbildungsverzeichnis Abkürzungsverzeichnis III III 1 Einleitung 1 2 Javascript WebGL SpiderGL XML3D X3DOM GUI Prototype jquery Dojo Toolkit GST Datenmodell Geometrien Eigenschaften Anwendung Räumlich unbegrenzte Modelle Architektur GST Web Datenbank Webserver Webbrowser GUI Layout Checkbox Tree Eigenschaftsdialog Zusammenfassung 34 Literatur 35

5 Abbildungsverzeichnis III Abbildungsverzeichnis 1 Würfel in WebGL erstellt mit SpiderGL Szenegraph zum X3DOM Beispiel Grafik zu X3DOM Vereinfachtes GST Datenmodell Ausschnitt des Datenmodells für TINs Drei-Schichten-Architektur von GST Oberflächenlayout Eigenschaftsdialog Interpolierte Fläche Farbwürfel Abkürzungsverzeichnis AJAX API CAD CMS CPU CSS DOM EU GeoSciML GIS GML GST GUI HTML HTTP IDE IIS ISO JSON KiB LOD Asynchronous Javascript and XML Application Programming Interface Computer Aided Design Content Management System Central Processing Unit Cascading Style Sheets Document Object Model Europäische Union Geoscience Markup Language Geographic Information System Geography Markup Language Geosciences in Space and Time Graphical User Interface Hypertext Markup Language Hypertext Transfer Protocol Integrated Development Environment Internet Information Service International Organization for Standardization Javascript Object Notation Kilobyte Level of Detail

6 Abbildungsverzeichnis IV NADM OGC PC PHP RIA SFS SVG TIN TU VRML W3DS WebGL WFS WKB WKT XML North American Geologic Map Data Model Open Geospatial Consortium Personal Computer PHP: Hypertext Preprocessor Rich Internet Application Simple Feature Standard Scalable Vector Graphics Triangulated Irregular Network Technische Universität Virtual Reality Modeling Language Web 3D Service Web Graphics Library Web Feature Service Well-known binary Well-known text Extensible Markup Language

7 1 Einleitung 1 1 Einleitung Die immer schneller ansteigende Rechenkapazität bei den Desktopcomputern der Nutzer ermöglicht diesen, rechenintensivere Anwendungen auszuführen. Dies wird beispielsweise durch zunehmend realistisch anmutende Spiele und Grafiken verdeutlicht. Um die verwendeten Grafiken berechnen und darstellen zu können, müssen Grafikkarten, Speicher und CPU leistungsfähiger sein als zuvor. Auch die Qualität und Quantität an Bildern und Filmen sowie die Funktionsvielfalt vieler Programme erfordern die Verbesserung der Leistungsfähigkeit von Computern. Gleichzeitig versuchen Hard- und Softwareentwickler die Systeme effizienter zu gestalten. Dabei wird einerseits darauf geachtet, dass vorhandene Ressourcen besser genutzt werden, zum Beispiel durch eine effizientere Speicherverwaltung oder die Nutzbarmachung der Grafikkarte für hoch parallelisierte Aufgaben. Andererseits werden neue Technologien eingeführt: z.b. Solid State Disks, welche viele und große Daten sehr schnell speichern im Vergleich zu herkömmlichen Festplatten oder aber auch Mehrkern Recheneinheiten, welche es den Systemen ermöglichen mehrere Aufgaben gleichzeitig auszuführen, werden eingesetzt. Ein weiterer Motor für die Entwicklung neuer Technologien ist die Konkurrenz auf den einzelnen Märkten. Gab es lange Zeit hauptsächlich nur zwei Webbrowser (Internet Explorer von Microsoft und Firefox von Mozilla), welche mit unterschiedlichen Konzepten versuchten mehr Nutzer zu gewinnen, gesellte sich durch die Entwicklung von Google Chrome durch Google ein zusätzlicher, aussichtsreicher Kandidat dazu[1]; weitere Browser, mit eher geringeren Marktanteilen, sind: Opera von Opera Software und Safari von Apple[2, 3]. Dadurch wurde gleichzeitig eine neue Ära eingeläutet. Die zeitgleiche Entwicklung des sog. Web 2.0, welches mehr Interaktion zwischen den Nutzern und den Webseiten ermöglichte, erforderte eine schnellere und effizientere Ausführung von Javascript, auf dem die meisten solcher Web 2.0 Webseiten basieren. Diese Entwicklungen und aufgrund des Verlangens der Nutzer auf Daten überall und Plattform unabhängig, d.h. unabhängig vom Gerät (Smartphone, Tablet PC, Notebook, Workstation etc.), aber auch unabhängig vom verwendeten Betriebssystem (Windows, Linux, Mac OS, Android etc.), zugreifen zu können, verlagern sich selbst klassische Anwendungen wie Textverarbeitung und Tabellenkalkulationen ins Internet. Es handelt sich hierbei um sog. Cloudcomputing. Darüber hinaus ermöglicht es mehreren Nutzern gleichzeitig auf die Daten zuzugreifen, ohne dass diese vorher ausgetauscht werden müssen[1]. In dieser Arbeit wird versucht eine solche Web 2.0 Anwendung zu erstellen. Die Anwendung soll es den Nutzern ermöglichen, sich geologische 3D Modelle interaktiv zu betrachten. Dazu werden neueste Technologien miteinander kombiniert:

8 1 Einleitung 2 die Speicherung der Geodaten erfolgt im neuartigen GST System der TU Bergakademie Freiberg, die 3D Darstellung der Modelle erfolgt über die WebGL Schnittstelle der Browser[4], die Oberfläche besteht aus HTML und Javascript. Der erste Teil der Arbeit setzt sich mit den verwendeten Javascript Bibliotheken auseinander. Im zweiten Teil wird das GST System beschrieben und erläutert, da es als Grundlage für die Anwendung dienen soll. Danach werden die Bestandteile der Anwendung erläutert und inwiefern Erweiterungen zu GST und aber auch zu den Javascript Bibliotheken durchgeführt wurden.

9 2 Javascript 3 2 Javascript Bei Javascript handelt es sich um eine Scriptsprache, welche dazu dient mehr Dynamik auf Webseiten zu schaffen. So lassen sich beispielsweise durch Javascript Effekte, wie Bewegung, Farb- und Bildwechsel etc., Dialoge, zur Information des Nutzers oder Abfrage von Daten, sowie das Nachladen von weiteren Inhalten realisieren. Die Syntax von Javascript ist an der Syntax der Programmiersprache C angelehnt. Javascript selbst untersteht keinem festen Programmierparadigma wie zum Beispiel C (prozedural) oder Java (objektorientiert), vielmehr kann in Javascript das Paradigma genutzt werden, welches am meisten den Ansprüchen der Anwendung als auch den Erfahrungen der Programmierer entspricht. Viele Webseiten nutzen heutzutage Javascript, um die Nutzer durch Interaktion zu binden (z.b. Facebook, Studivz) oder um weitere Funktionen zur Verfügung zu stellen (z.b. Google Text & Tabellen) Um zeitraubende und letztlich ineffektive Neuentwicklungen zu vermeiden und um die mehrfache Entwicklung unterschiedlicher Standards zu verhindern, ist es durchaus sinnvoll bereits vorhandene, fundierte und komplexe Bibliotheken zu nutzen. Diese erleichtern die Programmierung, in dem sie einerseits ausgefeilte Algorithmen verwenden, welche durch ständige Weiterentwicklung verbessert werden. Andererseits können solche Bibliotheken helfen die Unterschiede zwischen verschiedenen Browsern zu überwinden, in dem sie generalisierte Lösungen anbieten, welche im Hintergrund testen, welcher Browser vom Nutzer verwendet wird und somit die richtigen Methoden auswählen. Dies wird zum Beispiel deutlich, wenn es selbst um einfache Sachen wie HTTP Anfragen geht: In Listing 1 wird versucht ein Request Objekt zu erstellen. Bei Firefox, Opera, Safari sowie ab Internet Explorer 7 wird vom Browser das selbe Objekt (XMLHttpRequest) zur Verfügung gestellt. Sollte es dieses Objekt nicht geben, wird eine Ausnahme ausgelöst und es wird versucht das Objekt über unterschiedliche Methoden zu erzeugen. Sollte keine der hier aufgeführten Methoden zum Erfolg führen, wird das Objekt nicht erzeugt. Demzufolge kann es dann auch nicht weiter genutzt werden. Dem Nutzer sollte in einem solchen Fall eine geeignete Fehlermeldung ausgegeben werden. Listing 1: Erstellung HTTP Request Objekt var xmlhttp = null ; try { // F i r r e f o x, Opera, S a f a r i sowie I n t e r n e t Explorer ( ab v7 ) xmlhttp = new XMLHttpRequest ( ) ; } catch ( e ) {

10 2.1 WebGL 4 } try { } catch ( e ) { try { } // MS I n t e r n e t Explorer ( ab v6 ) xmlhttp = new ActiveXObject (" M i c r o s o f t.xmlhttp" ) ; // MS I n t e r n e t Explorer ( ab v5 ) xmlhttp = new ActiveXObject (" Msxml2.XMLHTTP" ) ; } catch ( e ) { xmlhttp = null ; } Diese Beispiel zeigt auch, dass selbst bei den selben Browserherstellern teilweise große Unterschiede in den einzelnen Javascript Implementierungen zu finden sind. Es lassen sich unzählige Beispiele finden, die unterschiedlich von verschiedenen Browsern implementiert wurden [5 7]. Auch gibt es Beispiele, die ähnliche Methodennamen besitzen, aber unterschiedlich interpretiert werden und demzufolge unterschiedliche Ergebnisse produzieren. In dieser Arbeit wurden hauptsächlich zwei Bibliotheken verwendet. WebGL basierte Darstellungen von 3D Objekten wurden mit Hilfe von X3DOM [8] realisiert. Interaktionen mit dem Benutzer des Systems werden durch das Dojo Toolkit[9] übernommen. Der folgende Abschnitt beschäftigt sich mit der Historie von WebGL und den unterschiedlichen Bibliotheken, welche entstanden sind und warum gerade X3DOM für die Umsetzung dieser Arbeit gewählt wurde. Im Abschnitt danach wird eine ähnliche Diskussion für das Dojo Toolkit und dessen Pendants durchgeführt. 2.1 WebGL Die ersten Seiten im Internet bestanden vorrangig aus Text. Später, als die Öffentlichkeit mehr Zugang zum Internet hatte, kamen Grafiken und Animationen hinzu. Heutzutage kann man sich ein Web ohne Interaktion und Animationen kaum vorstellen. Seiten wie Youtube würden ohne die von Adobe weiterentwickelte Flashtechnologie gar nicht bestehen. Da schon früh der Wunsch nach Grafiken und Animationen entstand, verwundert es auch nicht, dass seit dem ersten Tag ebenfalls daran gedacht wurde eventuell dreidimensionale Grafiken ins Web zu bringen. Erste Ansätze wurden beispielsweise mit

11 2.1 WebGL 5 VRML verfolgt. Um VRML-Dateien betrachten zu können waren bisher immer Plugins oder anderweitige Software nötig. Besaß ein Nutzer beispielsweise auf seinem PC nicht die Rechte, Software oder Plugins für seinen Browser zu installieren, musste er darauf verzichten sich ein solches Modell anschauen zu können. Mit dem <canvas> Element aus dem HTML 5 Standard[10] war es erstmals möglich Grafiken dynamisch auf einer Webseite zu erzeugen, ohne dass etwas vom Server nachgeladen werden musste. Dabei wurde extensiv SVG verwendet. Natürlich lassen sich auch damit recht rudimentär dreidimensionale Grafiken erstellen, aber sie werden einerseits nicht durch die Hardware beschleunigt und andererseits ist SVG darauf ausgelegt 2D Grafiken zu erstellen begann sich Mozilla verstärkt mit dem <canvas> Element auseinanderzusetzen. In Zusammenarbeit mit der Khronos Group konnte zu 2009 ein erster Entwurf für WebGL veröffentlicht werden, welcher nach und nach von den Browsern Firefox, Chrome und Safari unterstützt wurde. Microsoft hat bis heute keinerlei Andeutungen gemacht WebGL im kommenden Internet Explorer zu unterstützen[11]. WebGL basiert auf OpenGL ES 2.0. Dies ermöglicht somit Einsatz auf vielen verschiedenen Geräten mit verschiedenen Betriebssystemen. Es unterstützt eine Reihe von Befehlen, die auch in OpenGL implementiert sind. Durch die ähnliche Syntax von Javascript und C bzw. C++, wurden diese Befehle eins zu eins übernommen. Dies ermöglicht den Programmierern einen großen Teil der OpenGL Schnittstelle zu nutzen. Gleichzeitig bedeutet dies, dass man sich auch intensiver mit der 3D Programmierung auseinandersetzen muss. Nachdem eine 3D Szene wie auch immer definiert wurde (siehe SpiderGL, XML3D und X3DOM), wird sie durch WebGL gerendet, d.h. berechnet. WebGL bzw. OpenGL ES erzeugen aus den übergebenen Koordinaten und Indices Bilder. Die Indices bestimmen dabei in welcher Art und Weise die Vertices verbunden werden. Darüber hinaus wird berechnet, welche Objekte verdeckt sind und wie diese Objekte aussehen, was maßgeblich von den Eigenschaften, wie Farbe und Reflektionsvermögen, sowie Beleuchtung, also Winkel und Stärke des einfallenden Lichts, bestimmt wird. Auch gibt es Objekte, die sich außerhalb der Szene befinden können, welche dann einfach abgeschnitten werden[12]. Kurz nach dem Erscheinen der ersten Version von WebGL und den ersten Implementierungen in den Browsern entstanden Bibliotheken, welche es Internetentwicklern erleichtern sollten, Anwendungen mit WebGL zu erstellen, da die meisten dieser Entwickler sich zwar mit HTML, Javascript und PHP oder anderweitigen Serversprachen

12 2.1 WebGL 6 auskannten, aber keine oder wenige Erfahrungen mit der 3D Programmierung besaßen. Einige solcher Bibliotheken, welche in dieser Arbeit besprochen werden, sind: SpiderGL[13] XML3D[14] X3DOM[8]. Eine Liste weiterer solcher Frameworks, welche sich alle im Großen und Ganzen ähneln und in den Details Unterschiede aufweisen, findet man auf der Webseite The WebGL Coobook[15] SpiderGL SpiderGL liefert eine gute Basis für die Entwicklung von 3D Webanwendungen. Es beinhaltet eine Bibliothek mit mathematischen Funktionen, mit welchen Vektoren und Matrizen erstellt werden können, um damit beispielsweise die Positionen der Objekte im 3D Raum zu berechnen. Ebenso lassen sich Verschiebungen und Rotationen durchführen. Die von SpiderGL zur Verfügung gestellte Abstraktionsebene kann dabei an die Bedürfnisse und Erfahrungen der Entwickler angepasst werden. Leider stellt sich in der Praxis raus, dass die Entwicklung von SpiderGL seit Mitte 2010 nicht weiter vorangeschritten ist. Außerdem ist die Dokumentation nicht sehr umfassend, sodass es hier einiger Einarbeitung bedarf. Dies kann unter andrem daran liegen, dass es nur einen Entwickler dieser Bibliothek gegeben hat. Entgegen den zwei folgenden Systemen ist SpiderGL kein Szenegraph, sondern speichert die Geometrien in einem struct-of-arrays System, da Javascript damit schneller arbeiten kann[16]. Um 3D Objekte mit SpiderGL zu erzeugen, müssen diese zuerst in Quellcode umgewandelt und dann durch Aufrufe der API an das Backend weitergegeben werden. Listing 2 auf S. 7 zeigt ein Beispiel in Javascript. Es werden als erstes die Vertex Positionen als Array angelegt. Für jeden Vertex wird eine Farbe im Array boxcolors definiert. Damit das Backend die richtige Grafik erzeugt, muss vorher definiert werden, wie diese aufgebaut ist. Jede Seite des Würfels besteht aus einem Quadrat, welches wiederum in 2 Dreiecke zerlegt werden wird. Die Definition der Dreiecke wird durch boxtrglindices festgelegt. Hier werden die Indices gespeichert, welche zu dritt jeweils ein Dreieck bilden. Mit boxedgesindices werden die Kanten des Würfels definiert. Beide Arrays referenzieren die Vertices aus boxpositions. Schlussendlich wird über die SpiderGL API ein Mesh, also eine Vermaschung von Punkten, erzeugt. Diesem Mesh werden dann die vorher er-

13 2.1 WebGL 7 stellten Arrays übergeben und somit das Bild von einem Würfel erzeugt (siehe Abb. 1 auf S. 8). var ( [ ] ) ; Listing 2: Erstellung eines Würfels mit Hilfe von SpiderGL[17] b o x P o s i t i o n s = new Float32Array 0.5, 0.5, 0. 5, 0. 5, 0.5, 0. 5, 0.5, 0. 5, 0. 5, 0. 5, 0. 5, 0. 5, 0.5, 0.5, 0.5, 0. 5, 0.5, 0.5, 0.5, 0. 5, 0.5, 0. 5, 0. 5, 0.5 var boxcolors = new Float32Array ( [ 0. 0, 0. 0, 1. 0, 1. 0, 0. 0, 1. 0, 0. 0, 1. 0, 1. 0, 1. 0, 1. 0, 1. 0, 0. 0, 0. 0, 0. 0, 1. 0, 0. 0, 0. 0, 0. 0, 1. 0, 0. 0, 1. 0, 1. 0, 0. 0 ] ) ; var ( [ ] ) ; var ( [ ] ) ; b o x T r g l I n d i c e s = new Uint16Array 0, 1, 2, 2, 1, 3, // f r o n t 5, 4, 7, 7, 4, 6, // back 4, 0, 6, 6, 0, 2, // l e f t 1, 5, 3, 3, 5, 7, // r i g h t 2, 3, 6, 6, 3, 7, // top 4, 5, 0, 0, 5, 1 // bottom boxedgesindices = new Uint16Array 0, 1, 1, 3, 3, 2, 2, 0, // f r o n t 5, 4, 4, 6, 6, 7, 7, 5, // back 0, 4, 1, 5, 3, 7, 2, 6 // middle var box = new SglMeshGL ( g l ) ; box. addvertexattribute (" p o s i t i o n ", 3, b o x P o s i t i o n s ) ; box. addvertexattribute (" c o l o r ", 3, boxcolors ) ;

14 2.1 WebGL 8 box. addarrayprimitives (" v e r t i c e s ", g l. POINTS, 0, 8 ) ; box. addindexedprimitives (" t r i a n g l e s ", g l.triangles, b o x T r g l I n d i c e s ) ; box. addindexedprimitives (" edges ", g l. LINES, boxedgesindices ) ; Abb. 1: Würfel in WebGL erstellt mit dem Listing 2 auf S XML3D Im Gegensatz zu SpiderGL und vielen weiteren Frameworks beruhen sowohl XML3D als auch X3DOM (siehe X3DOM) auf einem völlig unterschiedlichen Ansatz. Hier wird versucht eine bereits vorhandene Beschreibungssprache XML in solcher Art und Weise zu erweitern und zu verwenden, dass 3D Szenen beschrieben werden können. Ein Vorteil hierbei ist, dass sich Webseiten Entwickler nicht erst mit 3D Programmierung auseinandersetzen müssen, sondern das sie bereits vorhandenes Wissen über HTML bzw. XML und CSS nutzen können, um eine solche Szene zu erstellen. XML3D verfolgt dabei einen unterschiedlichen Ansatz als X3DOM: Man versucht bisherige Technologien auszureizen, anstelle ein weiteres XML Format als Standard zu etablieren. Auf der anderen Seite muss für eine komplette Unterstützung der XML3D Spezifikation ein spezieller Browser heruntergeladen werden, was wiederum im Gegensatz zu der möglichen

15 2.1 WebGL 9 Plattformunabhängigkeit steht. Darüber hinaus gibt es auch eine Javascript Bibliothek, welche aber nur als Prototyp verwendet wird[18]. Im Rahmen dieser Arbeit wurde bei Tests der Bibliotheken XML3D und X3DOM festgestellt, dass die gerenderten Bilder von XML3D zwar schöner anzusehen sind, aber auch, dass XML3D dementsprechend nicht so leistungsfähig ist wie X3DOM und ein Bewegen in der 3D Szene teilweise von Ruckeln begleitet ist X3DOM X3DOM stellt eine ausgewachsene Abstraktionsebene zwischen den Entwicklern und WebGL zur Verfügung. Selbst als unerfahrener 3D Entwickler lassen sich leicht Anwendungen mit X3DOM konzipieren, welche mehr oder weniger komplizierte 3D Modelle zeigen. Die Entwicklung wird stetig von einem größeren Entwicklerteam vorangetrieben. Ein weiterer Pluspunkt für die Nutzung der Bibliothek ist, dass diese einen bereits existierenden Standard (X3D) verwendet und in HTML Seiten einbettet. Intern verwaltet X3DOM einen Szenegraphen, welcher synchron mit dem DOM gehalten wird. Dadurch spiegelt sich der Aufbau des Szenegraphen ebenda wider. Ebenso wie SpiderGL und XML3D, beinhaltet auch X3DOM eine Teilbibliothek für mathematische Operationen mit Vektoren, Matrizen und Quaternionen[19 21]. Dadurch, dass X3DOM auf X3D aufbaut, eignet es sich hervorragend für die Übertragung von dreidimensionalen Grafiken und Modellen. Diese können somit nicht nur auf einer Webseite interpretiert und dargestellt werden, sondern auch in Programmen, die X3D unterstützen, wie zum Beispiel Blender, 3D Studio Max und viele andere mehr. Bei X3DOM ist darauf zu achten, dass es den ISO Standard X3D nicht vollständig unterstützt. Es gibt bei X3D sog. Profile[22], welche von den verschiedenen Programmen implementiert werden. Zu jedem Profil gehört ein bestimmter Satz an Elementen aus der Spezifikation, welche unterstützt werden müssen. So kann es beispielsweise Programme geben, die nur einen Grundsatz an Elementen verstehen und in 3D Szenen umwandeln können, oder Programme, die alles aus der Spezifikation implementieren. In X3DOM wurde das»interchange Profile«implementiert[23, 24]. Listing 3 auf S. 10 zeigt ein einfaches Beispiel, wie eine 3D Szene mit Hilfe von X3DOM erstellt werden kann. Es werden hierbei zwei Transformationsknoten erstellt. Diese können später genutzt werden um alles, was ihnen untergeordnet ist, zu verschieben, zu rotieren und zu skalieren. Unter der Transformation mit dem Attribut id="t1" ist ein sog. Gruppenknoten, welcher die ihm untergeordneten Knoten in einer Gruppe zusammenfasst, platziert. Die Shapeelemente beschreiben jeweils eine Geometrie mit ihren dazugehörigen Eigenschaften, wie beispielsweise der Farbe. Darüber hinaus muss natürlich

16 2.1 WebGL 10 auch definiert werden um welche Geometrie es sich im Speziellen handelt und welche Koordinaten diese besitzt. Das Beispiel zeigt drei Linien, die senkrecht zueinander stehen und rot, grün bzw. blau eingefärbt sind. Zusätzlich wurde unter dem zweiten Transformationsknoten eine Linie erstellt, welche Diagonal im Raum mit der Farbe blau verläuft. Abb. 2 auf S. 11 stellt den entsprechenden Szenegraph für diese Szene dar. Abb. 3 auf S. 12 zeigt die entstehende Grafik. Listing 3: X3DOM Beispiel <x3d xmlns=" http : / /www. x3dom. org /x3dom" width="100px" height="100px"> <scene> <transform id=" t 1 "> <group id=" gr1 "> <shape id=" s1 "> <appearance> <material e m i s s i v e C o l o r="1 0 0"></material> </appearance> <indexedlineset coordindex="0 1 1"> <coordinate p o i n t=" "></ coordinate> </ indexedlineset> </shape> <shape id=" s2 "> <appearance> <material e m i s s i v e C o l o r="0 1 0"></material> </appearance> <indexedlineset coordindex="0 1 1"> <coordinate p o i n t=" "></ coordinate> </ indexedlineset> </shape> <shape id=" s3 "> <appearance> <material e m i s s i v e C o l o r="0 0 1"></material> </appearance> <indexedlineset coordindex="0 1 1"> <coordinate p o i n t=" "></ coordinate> </ indexedlineset> </shape> </group> </ transform> <transform id=" t 2 "> <shape id=" s4 "> <appearance> <material e m i s s i v e C o l o r="0 0 1"></material> </appearance> <indexedlineset coordindex="0 1 1"> <coordinate p o i n t=" "></ coordinate> </ indexedlineset>

17 2.2 GUI 11 </shape> </ transform> <viewpoint p o s i t i o n="0 0 3"></viewpoint> <background s k y C o l o r=" 0 0 0"></background> </ scene> </x3d> Abb. 2: Szenegraph zum X3DOM aus Listing 3 auf S. 10. Die Baumstruktur des Beispiels verdeutlicht ebenso die Struktur des dazugehörigen Szenegraphen. Aufgrund dessen, dass X3DOM einen vorhandenen Standard nutzt und sich in Tests leistungsfähiger als XML3D zeigte, wurde X3DOM zur Implementierung in dieser Arbeit genutzt. Der Ansatz, dieser beiden Frameworks, XML als Austauschformat zu nutzen, ist dem gegenüber SpiderGL vorzuziehen. Darüber hinaus existieren bereits Programme, die zum Exportieren von X3D genutzt werden können. Da bei der zu entwickelnden Anwendung häufig große Geometrien übertragen werden, welche beispielsweise aus und mehr Vertices, mit jeweils 3 Koordinaten, bestehen, fällt der Datenüberhang, welcher durch XML entsteht, nicht so sehr ins Gewicht. Zusätzlich sind die beiden zuletzt vorgestellten Projekte besser dokumentiert und werden aktiv weiter entwickelt. 2.2 GUI Neben den oben aufgeführten Bibliotheken, welche Entwicklern helfen leichter komplizierte 3D Webanwendungen zu schaffen, existieren auch viele Javascript Bibliotheken,

18 2.2 GUI 12 Abb. 3: Beispiel zum X3DOM aus Listing 3 auf S. 10. Drei senkrechte und eine diagonale Linie. welche einem das Leben mit der Erstellung von Webanwendungen allgemein erleichtern, in dem sie beispielsweise generische Ansätze liefern, die in unterschiedlichen Browsern die selben Ergebnisse liefern. Dies beinhaltet meist die Abstraktion spezifischer Vorgänge, kann aber auch durch GUI Funktionen erweitert werden. Meistens werden diese Erweiterungen im Zusammenhang mit AJAX verwendet. Was wiederum die Entwicklung von Webanwendungen, die sich ähnlich wie Desktopanwendungen verhalten, ermöglicht: So kann beispielsweise nur ein bestimmter Bereich einer Webseite aktualisiert werden, ohne dass die komplette Seite neu geladen werden muss. Gleichzeitig wird dafür gesorgt, dass eine solche Anfrage den Browser nicht blockiert, was bedeutet, dass der Nutzer die Anwendung weiter nutzen kann, während zum Beispiel ein Bild über das Internet nachgeladen wird. Die Antworten vom Server müssen nicht immer als XML kodiert sein. Wie bereits erwähnt, kann es sich ebenso um Bilder handeln oder auch Javascript Objekte in Form von JSON. Die Umwandlung von JSON in Javascript Objekte das Parsen übernimmt hierbei der Browser, somit muss dies nicht in der Anwendung selbst geschehen. Es kann quasi sofort nach der Übertragung des Objektes auf dessen Eigenschaften und ggf. Methoden zugegriffen werden Prototype Bereits 2005, als erste dynamische Webanwendungen (RIA) entstanden, wurde Prototype entwickelt, um den Entwicklern die Arbeit mit unterschiedlichen Browsern und auch Javascript zu erleichtern. So beinhaltet Prototype Funktionen, die es ermöglichen Elemente

19 2.2 GUI 13 der Webseite abzufragen, Inhalte nachzuladen und vieles weiteres. Prototype selbst beinhaltet wenig Elemente, die für eine wirkliche GUI genutzt werden können. Zusammen mit der Bibliothek Scriptaculous kann diese Beschränkung teilweise aufgehoben werden. In Verbindung mit Ruby on Rails wird Prototype oft verwendet, um RIAs zu entwickeln. Der Entwickler nutzt dabei eine Entwicklungsumgebung (IDE) und schreibt seinen Code beispielsweise in Ruby. Die IDE erstellt aus diesem Quellcode dann entsprechende HTML Seiten und Javascript Funktionen, sodass sich der Programmierer nicht mehr mit den Einzelheiten auseinandersetzen muss, z.b. wie bestimmte Funktionen mit Prototype realisiert werden. Ein weiterer Nachteil von Prototype ist, dass es auf Basis der Erweiterung des DOM entwickelt wurde. Dies bringt neben Einbußen in der Leistungsfähigkeit, durch sog. Overhead und eventuellen Namenskonflikten, auch Probleme mit den verschiedenen Browsern mit sich («IE DOM is a mess»[25]) jquery jquery wird ähnlich lange wie Prototype entwickelt, nur dass hier ein anderer Ansatz gewählt wurde. Erstens erweitert jquery nicht das DOM sondern stellt in einem eigenen Namensraum Funktionen für den Entwickler zur Verfügung. Zweitens stellt jquery nicht nur Funktionen für den Entwickler bereit, sondern zusätzlich auch grafische Elemente, welche zur Interaktion mit den Nutzern genutzt werden können, wie zum Beispiel: Buttons, Dialoge, Tabs, Fortschrittsbalken etc. Darüber hinaus ist es möglich über sog. Plugins gemeint sind Javascript Plugins zusätzliche Funktionen und Oberflächenelemente zur Verfügung zu stellen. Diese Bibliothek wird von vielen bekannten Unternehmen genutzt, um deren Webseite mit dynamischen Inhalten zu versorgen, z.b. Dell, Mozilla. Zusätzlich findet jquery weitere Verbreitung über die Blogsoftware Wordpress und das CMS Drupal. Ähnlich wie Prototype wird jquery durch einen Scripttag auf der Seite verfügbar gemacht: <script src="libs/jquery/1.6.2/jquery.min.js"></script>. Diese Zeile bindet die jquery Bibliothek ein. Das min im Dateinamen bedeutet, dass es sich um eine verkleinerte Version handelt, d.h., dass Kommentare sowie Leerzeichen und Zeilenumbrüche weitestgehend entfernt wurden. Hinzukommt, dass versucht wird lange Variablen- und Funktionsnamen möglichst kurz zu halten. So verkleinert die Größe der Bibliothek sich von 229 KiB auf 84 KiB bzw. komprimiert 31 KiB. Somit kann gewährleistet werden, dass die Downloadzeit für die Bibliothek, trotz ihres Funktionsumfangs, möglichst gering bleibt[26].

20 2.2 GUI Dojo Toolkit Das Dojo Toolkit ist vergleichbar mit jquery. Es wird ebenfalls von vielen Unternehmen zur Erstellung der Firmenwebsites genutzt. Darunter sind u.a. IBM, AOL, Cisco und Sun. Im Gegensatz zu jquery bietet Dojo von Grund auf mehr Funktionalitäten. Diese sind in eigene Namensräume gepackt: dojo dient als Basis. Grundlegende Funktionen für AJAX-Anfragen, Abfrage und Manipulation von DOM Elementen, Eventbehandlung u.a. dijit baut auf dojo auf und liefert Funktionen und HTML Elemente, die zur Erstellung einer komplexen Nutzeroberfläche genutzt werden können. dojox beinhaltet zusätzliche Module, die weitere Oberflächen Elemente liefern. Darüber hinaus ist in dojox ein Modul enthalten mit dem sich beispielsweise Grafiken on-the-fly erstellen lassen. Da das Dojo Toolkit recht umfangreich ist, bietet es die Möglichkeit einzelne Module mit einem dojo. require (); nachzuladen. Dies entspricht sinngemäß einer Include Anweisung, wie sie in C und C++ implementiert ist. Somit muss beim Laden der Webseite nicht das gesamte Toolkit geladen werden, sondern nur die Basis, was die anfängliche Ladezeit deutlich verringert. Dojo ist darauf ausgelegt komplexe Anwendungen zu schreiben. Deshalb sind die Widgets, so werden die einzelnen Klassen genannt, auch erweiterbar. Somit können beispielsweise Widgets um eigene Methoden erweitert oder das ursprüngliche Verhalten verändert werden. Dies wurde auch in dieser Arbeit getan, um ein sog. Checkbox Tree Widget zu erstellen (siehe Checkbox Tree). Um die mit Dojo erzeugten Anwendungen auf möglichst vielen Geräten (PC, Tablet, Smartphone) und in möglichst vielen Browsern (IE, Firefox, Chrome, Safari, Opera) ausführen zu können, legen die Autoren sehr viel Wert, dass der Code mit sog. Validatoren validiert werden kann, d.h. dieser wird gegen die HTML Spezifikation geprüft und beinhaltet keine Verstöße gegen sie. Dies ist unter anderem eine Grundlage dafür, dass die Webseite in verschiedenen Webbrowsern gleich aussieht. Es gibt bei der Benutzung von Dojo zwei Wege, Instanzen von den Widgets zu erstellen. Einer besteht darin HTML Elemente mit speziellen Attributen zu versehen: data-dojo-type und data-dojo-props. Das erste Attribut dient dazu, den Typen des Widgets zu bestimmen, beispielsweise dijit.form.button. Mit dem zweiten Attribut können die Eigenschaften, wie zum Beispiel Beschriftung, Verhalten bei einem Klick auf

21 2.2 GUI 15 das Element etc. festgelegt werden. Ein weiterer Weg ist, diese Widgets per Javascript zu erzeugen und dann in Containern zu platzieren (siehe Listing 4 auf S. 15). Listing 4: Erzeugung eines dojo Widgets per Javascript // r e g i s t e r a new t r e e with the model b e f o r e and // add i t to the div f e a t u r e T r e e var t r e e = new CheckBoxTree ( { model : treemodel, showroot : f a l s e }, " f e a t u r e T r e e " ) ; Die Leistungsfähigkeit und gleichzeitige Modularisierung sprechen für das Dojo Toolkit. Es stellt neben den grundlegenden und notwendigen Funktionen eine große Menge an Elementen für die Erstellung komplexer Nutzeroberflächen bereit. Die Möglichkeit der Erweiterung und des Überschreibens der vorhandenen Widgets ist ein weiterer Pluspunkt für dieses Framework.

22 3 GST 16 3 GST GST steht für Geosciences in Space and Time und wurde im Rahmen des EU Projektes ProMine an der TU Bergakademie Freiberg entwickelt. Dieses System befähigt den Nutzer dreidimensionale Daten zusammen mit deren Eigenschaften in einer Datenbank abzuspeichern. Diese Notwendigkeit besteht beispielsweise in den Geowissenschaften, wo der Untergrund mit 3D Modellierungswerkzeugen, wie zum Beispiel CAD, mit Hilfe von Bohrungsdaten nachgebildet wird. Auf einem solchen Modell werden dann relevante Informationen gespeichert, die verschiedene Skalenniveaus besitzen können (kategoriell, relativ, reell). Darüber hinaus besitzen solche Eigenschaften bei unterschiedlichen Modellierern unterschiedliche Bezeichnungen. Demzufolge war es notwendig, bei der Konzipierung des Datenmodells, eine größtmögliche Flexibilität zu schaffen. GST ist zudem recht einfach auf weitere Datenbanksysteme übertragbar. Um mit der entstandenen Datenbank zu kommunizieren, wurde ebenfalls ein Client entwickelt, welcher entweder als Plugin zu der Modellierungssoftware gocad oder auch als eigenständiges Programm ausgeführt werden kann. Die Software gewährleistet, dass selbst Nutzer, die über keine Lizenzen für gocad verfügen, mit der entwickelten Datenbank arbeiten können. Die Software bietet unterschiedliche Möglichkeiten, um auf die Datenbank zuzugreifen (siehe Abb. 6 auf S. 22): entweder direkt oder über einen zwischen geschalteten Webservice. Neben GST gibt es weitere Systeme, die über eine ähnliche Funktionalität verfügen. Es existiert beispielsweise die PostgreSQL Erweiterung PostGIS, welche es den Nutzern von dem Datenbanksystem PostgreSQL erlaubt georefrenzierte Daten mitsamt ihren Eigenschaften abzuspeichern. In der aktuellen Version von PostGIS sind dabei aber nur zweidimensionale Geometrien zugelassen, d.h. es handelt sich meist eher um Karten. Die Firma TIBCO bietet für Unternehmen eine eigens entwickelte Anwendung an, welche es ermöglicht CAD Daten zu speichern. Das System Open Spirit ist dahingehend ausgelegt möglichst viele verschiedene CAD Programme zu unterstützen. Der Nachteil dieser Software ist, dass eine weitere Datenbank auf einem Server installiert werden muss und nicht das evtl. bereits vorhandene Datenbanksystem genutzt werden kann. Ein weiteres Konkurrenzprodukt wird von der Firma Beak Consultants vertrieben. Der Ansatz dieses Datenmodells beruht auf sog. virtuellen Bohrungen, d.h. selbst an Stellen wo keine Daten vorhanden sind, wird mit Hilfe von Interpolation, eine Stützstelle des Modells geschaffen. Durch die so entstehende Rasterung, mit zum Beispiel 50 mal 50

23 3.1 Datenmodell 17 Metern, lassen sich Schnittbilder und Blockmodelle sehr schnell generieren. Ein Nachteil dabei ist, dass feinere Strukturen, die kleiner als 50 Meter sind, nicht richtig erfasst werden. Zusätzlich könnte man durch die virtuellen Bohrungen darauf schließen, dass mehr Daten vorhanden sind, als ursprünglich erhoben wurden. GST vereint die positiven Eigenschaften dieser Systeme miteinander: es ist portabel, es speichert dreidimensionale Geometrien und deren Eigenschaften, es ist unabhängig von der verwendeten Modelliersoftware, es werden nur Daten gespeichert, die auch vorhanden sind. Im Folgenden wird näher auf das Datenmodell, sowie die grundlegende Architektur von GST eingegangen. 3.1 Datenmodell Das Datenmodell von GST basiert auf verschiedenen vorangegangenen Projekten und Ideen. Dazu zählen beispielsweise das von Apel[27] entwickelte und später von Pouliot[28] weiterentwickelte Modell. Apel bemühte sich Daten aus der Modellierungssoftware gocad möglichst genau in einer XML Datenbank zu speichern. Um die dazugehörigen Eigenschaften der modellierten Geometrien abzuspeichern, bediente er sich am NADM, welches wiederum ein Vorgänger des GeoSciML ist. Pouliots Arbeit greift einige Ideen von Apel auf, nur dass sie die Daten über einen sog. Web Geological Feature Service, also einem erweiterten Web Feature Service, den Nutzern zur Verfügung stellt. D.h. dass beim zweiten Ansatz vermehrt versucht wurde bereits existierende Standards zu nutzen Geometrien Um so nah wie möglich am Standard zu bleiben und auch inspiriert durch das Design von PostGIS, gibt es folgende Geometrietypen in GST: Multipoint beinhaltet einen oder mehrere Punkte, Multilinestring beinhaltet eine oder mehrere Linien zwischen zwei Punkten, TIN beinhaltet eine oder mehrere Dreiecksvermaschungen, die wiederum aus einem oder mehreren Dreiecken bestehen,

24 3.1 Datenmodell 18 Multipolygon beinhaltet ein oder mehrere Tetraedervermaschungen, die wiederum aus einem oder mehreren Tetraedern bestehen, Geocollection beinhaltet ein oder mehrere gleiche oder auch unterschiedliche der vorher aufgeführten Typen. Abb. 4: Vereinfachtes GST Datenmodell, welches die Vererbung und Beziehung von Geocollection zu den übrigen Typen zeigt. Im Gegensatz zu dem weitverbreiteten PostGIS, können bei GST echte dreidimensionale Geometrien gespeichert und verwaltet werden. Alle hier aufgeführten Typen besitzen drei gleiche Eigenschaften: Eine id, welche die spezielle Geometrie eindeutig im Datenbanksystem identifiziert, einen geotype, welcher speichert, welchen Typ diese Geometrie hat, und eine box welche eine achsenparallele, die Geometrie umspannende, Boundingbox speichert. Ein vereinfachtes Datenmodell zeigt Abb. 4. Abb. 5 auf S. 19 stellt dar, wie z.b. eine Fläche in der Datenbank aufgebaut ist. So besteht ein TIN aus mindestens einem TFace, welches wiederum aus mindestens einem Trgl, Dreieck, besteht. Da gst.tin direkt von gst.geometry erbt, übernimmt es dementsprechend auch die Eigenschaften id, geotype, box. Da eine Fläche aus mehreren Teilflächen(gst.tface) bestehen kann besitzen diese ebenfalls eine eigene id. Außerdem verweisen sie auf die Geometrie, zu der sie gehören. Dies wird insbesondere dann wichtig, wenn die Eigenschaften den Geometrien besonders schnell zugeordnet werden sollen. Die gewonnene Geschwindigkeit bei den Abfragen wird zu Lasten einer Datenredundanz geschaffen. Jedes Dreieck in gst.trgl referenziert das TFace, zu dem es gehört. Außerdem besitzt jedes Dreieck einen Index

25 GST - DB Module v Datenmodell gst.tin gst.geometry <<geotable>> <<prostable>> VERTEX gst.proscatalog gst.vrtx _shape <<geotable>> gst.tin idgeo idx x y z _idgeo _idx <<prostable>> gst.tface id idgeo gst.trgl idtface idx idvrtx[3] _idgeo _idx <<prostable>> <<geotable>> <<prostable>> CENTROID gst.proscatalog gst.multipolygon Abb. 5: Ein Ausschnitt des Datenbankmodells für die Modellierung von Dreiecksvermaschungen. In Blau werden die Falle einer Realisierung eintretenden Referenzierungen gezeigt. gst.geometry <<geotable>> <<prostable>> VERTEX gst.proscatalog (idx), der das Dreieck innerhalb des TFace identifiziert. Der Grundstock jeder Geometrie sind die Vertices, welche in der Relation gst.vrtx gespeichert werden. Jeder Vertex besitzt einen Index und weiß, zu welcher Geometrie er gehört. gst.vrtx _shape <<geotable>> Eigenschaften gst.multipolygon idgeo _idgeo _idx <<prostable>> idx Um nicht auf ein spezielles Eigenschaftsmodell x festgelegt zu sein, wurde ein flexibler Ansatz zur Speicherung der Eigenschaften gewählt, y der es den Modellierern erlaubt sowohl den Name der Eigenschaft, als auch derenz Skalenniveau festzulegen. Dies ist ähnlich in PostGIS geregelt. Außerdemgst.tetra ist es möglich die Eigenschaften auf den einzelnen Vertices gst.tsolid aber ebenso auf den Teilen des Modells zu speichern. Dies bedeutet zum Beispiel für idtsolid eine triangulierte id Fläche, dass idx einzelne Dreiecke ebenso _idgeo Eigenschaften _idx <<prostable>> besitzen können. idgeo Dadurch ist es GST möglichidvrtx[4] mit weiteren CAD Systemen, außer gocad, zusammenzuarbeiten. Die Speicherung der Eigenschaften erfolgt in einer weiteren Tabelle, die vor Beginn der <<geotable>> <<prostable>> CENTROID gst.proscatalog Modellierung vom Datenbankadministrator, in Zusammenarbeit mit den Modellierern, angelegt wird. In Abb. 5 wird dies durch die Relation prostable gekennzeichnet. Page 5/28

26 3.1 Datenmodell 20 Die Informationen, wie die Eigenschaften einer Geometrie auf diese anzuwenden sind, werden in einer Systemtabelle gst.proscatalog gespeichert. Dies ermöglicht den Nutzern und dem System zu jeder Zeit überprüfen zu können, ob und wie eine Eigenschaftszuweisung für eine spezielle Geometrienklasse vorliegt Anwendung Um GST effizient nutzen zu können, müssen die Modellierer ihre Objekte in bestimmte Klassen einteilen. Die Erfahrung und Gespräche mit verschiedenen Modellierern zeigten, dass dies ein gängiger Ansatz ist. Die Objekte eines Modells können zum Beispiel in folgende Klassen, mit den jeweiligen Eigenschaften, eingeteilt werden: Messpunkte (als Multipoint), Bohrungen (als Multilinestring), Basishorizonte (als TIN mit einer Eigenschaft auf Objektebene), Störungsflächen (als TIN mit mehreren Eigenschaften auf Vertexebene), Erzkörper (als Multipolygon). Um die Objekte in der Datenbank speichern zu können müssen die entsprechenden Klassen angelegt werden. Dies kann mit Hilfe grundlegender SQL Befehle getan werden: CREATE TABLE f a u l t ( id b i g i n t not null, name varchar (50) ) ; CREATE TABLE fault_property ( dip double, s t r i k e double ) ; SELECT g s t. addgeocolumn ( f a u l t s, shape, TIN, 1, fault_property, VERTEX ) ; Es werden zu Beginn zwei Tabellen angelegt. Eine wird später ein Interface zu den Geometrien darstellen Die zweite Tabelle wird zu Speicherung der Eigenschaften, hier dip und strike, genutzt. Durch Ausführung der Funktion addgeocolumn werden die Tabellen erweitert. So erhält die Tabelle fault eine zusätzliche Spalte shape in welcher eine Referenz auf die Geometrie abgespeichert wird. Der Relation fault_property werden zwei Spalten hinzugefügt. Eine enthält eine Referenz auf die Geometrie und eine weitere, welche eine Referenz auf den Vertex enthält, welcher den konkreten Wert besitzt. Die Beispiele für die anderen Klassen ähneln diesem.

27 3.1 Datenmodell 21 So lassen sich über Stored Procedures Methoden erstellen, welche über einen bestimmten Eigenschaftswert ein Objekt suchen und für die Darstellung ausgeben Räumlich unbegrenzte Modelle Bei der Modellierung sehr großer Gebiete, beispielsweise eines Bundeslandes, stößt man, selbst mit heutigen Rechnern, an die Grenzen. Es bestehen mehrere Möglichkeiten mit diesen Grenzen umzugehen. Eine besteht darin, den Detailgrad, mit dem modelliert wird, soweit herabzusetzen, dass die Modelle wieder mit den vorhandenen PCs handhabbar werden. Bei der Modellierung ist ein solcher Ansatz nicht tragbar. Dieses Konzept wird jedoch bei der Visualisierung durch sog. LOD realisiert. Befindet sich ein Nutzer in einer hohen Entfernung von einem Objekt, wird dieses abstrahiert. Nähert sich der Nutzer dem Objekt, werden auch die feineren Strukturen dargestellt. Ein weiterer Ansatz besteht darin, dass große Gebiet in viele kleine Teilgebiete zu unterteilen. Eine sog. Kachelung ist gerade im Zusammenhang mit Geodaten durchaus üblich. Ein prominentes Beispiel für eine solche Kachelung ist Google Maps: Navigiert der Benutzer, durch Verschieben oder Zoom, mit hoher Geschwindigkeit über das Kartenmaterial, lassen sich von Zeit zu Zeit graue Quadrate ausmachen. Dies sind die Kacheln, die vom System angelegt werden. Dadurch wird es möglich, dass nicht das gesamte Kartenmaterial auf einmal geladen werden muss, sondern nur der gerade sichtbare Teil sowie ein paar weitere Kacheln als Puffer. Der Nachteil hierbei ist, dass die Kachelränder konsistent sein müssen. Ein 3D Modell, welches in einer Kachel einen z-wert von 400 und in der benachbarten Kachel, an der selben Stelle, sprich x- und y-wert sind gleich, einen z-wert von 4000 aufweist, ist nicht stimmig. Darüber hinaus kann es vorkommen, dass sich nach gewisser Zeit die Datenbasis, mit der das Modell erstellt wurde, verändert oder erweitert. Dies bedeutet bei einer Kachelung, dass in vielen Fällen eine Änderung in mehreren Kacheln vorgenommen werden muss. Durch eine Speicherung frei von Kacheln kann der Arbeitsaufwand für den Modellierr hier minimiert werden. Die Masterarbeit von Gietzel[29] beschäftigt sich eingehend mit solchen räumlich unbegrenzten Modellen und deren Speicherung innerhalb von GST. Darüber hinaus wurde im Rahmen von Gietzels Arbeit eine Schnittstelle zur Erstellung des Modells in verschiedenen Detailstufen (LOD) realisiert. Damit das Arbeiten an einem solch großen Modell möglich ist, wurden zusätzliche Sperrsysteme implementiert, die die herkömmlichen Sperrsysteme des Datenbanksystems erweitern, da für GST besondere Bedingungen gelten:

28 3.2 Architektur 22 die Daten sind über mehrere Tabellen verteilt, es müssen also mehrere Tabellen gesperrt werden und die Sperre einer Tabelle muss unter Umständen länger als eine Transaktion sein, da sich ein Benutzer zur Bearbeitung ein Modell aus der Datenbank lädt, danach damit evtl. mehrere Stunden arbeitet und dann erst wieder in die Datenbank lädt. Änderungen, die in der Zwischenzeit durchgeführt werden, werden dann wieder überschrieben. 3.2 Architektur Die eigentliche Architektur von GST sieht eine sog. Drei-Schichten-Architektur vor (siehe Abb. 6), d.h. es gibt eine Datenbank, in der die Daten gehalten werden, und eine Clientsoftware, mit der die Daten abgefragt werden und dargestellt werden können. Bei der vorgeschlagenen Idee gibt es eine weitere Software, die zwischen Datenspeicher und Client arbeitet und somit die Datenbank vor direktem Zugriff schützt. Solche Systeme werden häufig in produktiven Umgebungen von Unternehmen genutzt, da man so nicht jedem Benutzer Zugriff auf die Datenbank gewähren muss. Darüber hinaus ist es bei einer Zwei-Schichten-Architektur durchaus üblich einen sog. Fat-Client zu haben, der einen Großteil der Rechenarbeit übernimmt. Viewer Client (WFS, GML) GST webservice (WFS) DB direct (SQL, SFS) Database Modeller Client (Gocad) Further Client (standalone) Admin Client Abb. 6: Vorgeschlagene Drei-Schichten-Architektur. Ebenfalls möglich ist eine direkte Kommunikation mit der Datenbank, also eine Zwei-Schichten-Architektur. Um Zeit einerseits bei der Entwicklung und andererseits bei der Übertragung der Daten zu sparen, besitzt die Clientsoftware von GST die Möglichkeit direkt auf die Datenbank zuzugreifen. Dies erspart den Zwischenschritt, dass erst eine weitere Software, beispielsweise ein Webserver, die Daten aus der Datenbank holt und danach an den Clienten schickt.

29 3.2 Architektur 23 Bei der Entwicklung von GST wurde darauf geachtet, vorhandene Standards zu nutzen. So werden die Daten aus der Datenbank im Simple Feature Standard (SFS)[30] übertragen. SFS wurde vom Open Geospatial Consortium (OGC) entwickelt und dient dazu die Kommunikation zwischen Datenanbietern, also Datenbanken, und Datennutzern, also Clienten, zu vereinheitlichen. Zusätzlich definiert der Standard, welche Funktionen auf Seiten der Datenbank vorhanden sein müssen, wie zum Beispiel: Equals(g1, g2) - testet auf Gleichheit der Geometrien g1 und g2 und gibt in diesem Fall»wahr«zurück, Disjoint(g1, g2) - testet, ob die Geometrien g1 und g2 sich nicht überschneiden und gibt in diesem Fall»wahr«zurück, Within(g1, g2) - testet, ob Geometrie g1 innerhalb von Geometrie g2 ist und gibt in diesem Fall»wahr«zurück[30]. SFS bietet zwei mögliche Implementierungen entweder als sog. Well-known text (WKT) oder Well-known binary (WKB). Erstere Möglichkeit kodiert die Geometrie in Text, die zweite Möglichkeit als binären Code. Wie diese genau aufgebaut sind, kann im Standard[30] nachgelesen werden. Bei der Nutzung von WKB kann die Größe der Daten nochmal verringert und somit auch die Transportzeit von Datenbank zu Client verringert werden. Bisher wurde SFS hauptsächlich von PostGIS[31], einer Erweiterung zur Speicherung von georeferenzierten Daten in dem Opensource Datenbanksystem PostgreSQL[32], genutzt, um Geometrien mit den Clienten, wie QGIS, ArcGIS u.a., auszutauschen. Diese stellen die Geometrien dann im Hauptfenster dar. Da die meisten der konventionellen GI Systeme auf zwei Dimensionen beschränkt sind, also zur Kartenerstellung genutzt werden, bietet PostGIS bisher auch nur eine Schnittstelle zur Speicherung von zweidimensionalen Geometrien an. Der Standard bietet aber auch an, dreidimensionale Geometrien und sogar zeitlich indizierte Daten zu übertragen. Diese Möglichkeit wurde von GST genutzt. Zusätzlich wurden einige Änderungen implementiert, sodass bei der Übertragung der Geometrie die Datenmenge geringer wird. Dies wird von GST als SFS+ bezeichnet und betrifft vor allem die Dreickecksvermaschungen (TIN). Um die Daten über einen Webservice weiter zu verteilen, bieten sich verschiedene Möglichkeiten: WFS - Web Feature Service[33], W3DS - Web 3D Service.

30 3.2 Architektur 24 WFS besitzt den Vorteil bereits Standard des OGC und darüber hinaus auch ISO Standard zu sein. Es gibt viele Programme, die bereits mit Web Feature Services kommunizieren können. Dazu gehören u.a. die bereits oben aufgeführten QGIS und ArcGIS. Ein bedeutender Nachteil ist, dass mindestens der GML Standard[34] unterstützt werden muss, um die Geometrien zu kodieren. Es besteht zwar die Möglichkeit alle von GST bisher unterstützten Geometrietypen (siehe 3.1 Datenmodell) mit GML auszudrücken, aber dafür müssen die vorhandenen Elemente in unkonventioneller Art und Weise genutzt werden. Darüber hinaus existieren bisher keine Clienten, welche dreidimensionales GML unterstützen, da es bisher nur zur Übertragung von ebenen Geometrien (Punkte, Linien, Flächen) genutzt wurde. W3DS ermöglicht es die Geometrien standardmäßig als X3D zu übertragen. X3D erlaubt es einfacher eigene Typen zu kreieren, da der Aufbau ähnlich dem Aufbau von GST ist. Leider ist der Standard bisher ein Entwurf und es existieren ebenso wenig Clientprogramme wie für einen WFS mit dreidimensionaler Funktionalität. Die Übertragung der Eigenschaften kann zum Beispiel mit Hilfe von GeoSciML[35] passieren. GeoSciML ist ein auf XML basierendes Austauschformat für geologische Sachverhalte. Dabei bietet es viele Spezialisierungen. So kann ein geneigter Modellierer mit Hilfe von GeoSciML ein Gestein bestimmen. Darüber hinaus lassen sich vielmehr die einzelnen mineralogische Bestandteile sowie das vorhergehende Gestein und dessen mineralogische Zusammensetzung wiederum speichern. Die Zusammensetzung der Minerale kann auf die Ebene der Elemente so übertragen werden. GeoSciML liefert aber keinen Ansatz, wie solche Angaben zwischen verschiedenen Ländern einheitlich gestaltet werden können. Mit Hilfe von GML und GeoSciML lässt sich ein sog. Anwendungsschema erstellen, welches speziell auf eine Anwendung zugeschnitten ist. Dieses Schema dient dann als Grundlage für den Datenaustausch zwischen Server und Client. Demzufolge muss es genau beschreiben, wie bestimmte Typen, beispielsweise anhand der oben genannten Standards, aufgebaut sind. Da der von GST entwickelte Client der bisher einzige wäre, welcher einen der beiden oder auch beide Services unterstützen würde, wurde bisher darauf verzichtet dieses System dahingehend zu erweitern.

31 4 GST Web 25 4 GST Web Die im Rahmen dieser Arbeit erstellte Anwendung besteht aus mehreren Teilen. So wurde die Datenbank um Funktionen erweitert, die es ihr ermöglichen direkt X3D auszugeben. Auch, wenn diese Aufgabe durch einen Webserver oder eine andere Middleware übernommen werden könnte, wurde explizit dieser Ansatz gewählt, um die entstehenden Arbeitsschritte zeitlich so kurz wie möglich zu gestalten. Dies bedeutet beispielsweise, dass der Webserver nicht das von der Datenbank gelieferte SFS oder auch SFS+ parsen und in X3D umwandeln muss. Ein weiterer Vorteil hierbei ist, dass die Server Anwendung sehr einfach und klein gehalten werden kann und nur als Lieferant zwischen Webbrowser und Datenbank agiert. Der komplizierteste Teil der Anwendung ist sicherlich die Implementierung der Oberfläche im Browser, da hier zwei Ansätze zusammengebracht wurden: X3DOM und Dojo. Wie bereits erwähnt wurde auf dem Webserver ein Teil der Anwendung so entwickelt, dass dieser nur als Transporter zwischen den zwei Systemen genutzt wird. Im Folgenden werden zu erst die Erweiterung zur Datenbank und die Anwendung auf dem Webserver beschrieben. Der dritte Teil beschäftigt sich eingehend mit der erstellten Oberfläche und deren Funktionen bzw. welche Erweiterungen gemacht wurden, damit die gewünschte Funktionalität entsteht. 4.1 Datenbank Die Datenbank wurde an mehreren Stellen erweitert. So wurde für jeden im GST System vorhandenen Geometrietypen eine Ausgabe als X3D implementiert. Dies ermöglicht neben der Einbindung in die Weboberfläche auch einen Export in weitere Modellierungstools wie Blender oder ähnlichem. Die direkte Ausgabe in das Austauschformat X3D verringert die Wartezeit der Clientsoftware erheblich. Würde die Datenbank in einem ersten Schritt SFS oder auch SFS+ zurückgeben, müsste im Webserver diese Repräsentation der Geometrie mehr oder weniger umständlich in X3D umgewandelt werden. Bei der aktuellen Implementierung wird somit ein Zwischenschritt eingespart. Zusätzlich wurde das System dahingehend erweitert, dass es Objekte erstellen kann, welche einen bestimmten Wert in einer bestimmten Eigenschaft besitzen. Sind in einer solchen Datenbank zum Beispiel verschiedene Flächen, die Basishorizonte darstellen, mit den dazugehörigen Messwerten für Cadmium und weitere Schwermetalle abgespeichert, lassen sich alle Teilflächen zurückgeben, die einen bestimmten Schwellenwert überschreiten. Damit liefert das System die Möglichkeit wie konventionelle GIS benutzt zu werden.

32 4.2 Webserver 26 Hinzukommend müssen aber auch solche Funktionen implementiert werden, welche geometrische Bedingungen erfüllen können, zum Beispiel: alle Flächen mit einer Hangneigung größer als 3 %. Erst dann unterscheidet sich die Funktionalität erheblich von bisherigen zweidimensionalen Systemen. Um ein Objekt zu erhalten, welches die Bedingungen erfüllt, werden zuerst alle Vertices gesammelt, welche die Vorgaben erfüllen. Über die übergeordneten topologischen Elemente, beispielsweise Dreiecke bei einer Dreiecksvermaschung oder Tetraeder bei einer Tetraedervermaschung, lassen sich die benachbarten Vertices finden. Es werden also nicht nur die Vertices zurückgegeben, welche die Bedingung erfüllen, sondern auch jene, die nötig sind, um das Teilobjekt (Linie, Dreieck oder Tetraeder) zu generieren. 4.2 Webserver Zur Implementierung auf dem Webserver wurde die weit verbreitete Skriptsprache PHP verwendet. Dies ermöglicht den Einsatz diesen Teils nicht nur auf Apache Webservern, sondern zum Beispiel auch auf dem IIS von Microsoft. Im Wesentlichen besteht die Anwendung auf der Seite des Webservers aus fünf Dateien: features.php fragt die Datenbank ab, welche Klassen und Objekte in ihr abgespeichert sind. Die Daten werden dann über JSON an den Webbrowser gesendet und dort im Checkbox Tree dargestellt. getobejct.php liefert von der Datenbank ein Objekt an den Webbrowser zurück. properties.php fragt die zu einer Klasse möglichen Eigenschaften ab und liefert diese als JSON zurück. Diese Funktion wird beim Anzeigen der Eigenschaften sowie im Query-Editor genutzt. getproperties.php liefert die konkreten Werte einer Eigenschaft von einem konkreten Objekt. Die Werte werden dann im Grid des Eigenschaftsfensters dargestellt. getobjectconstr.php liefert den Teil eines Objektes zurück, der die Bedingungen, die mit Hilfe des Query-Editors erstellt wurden, erfüllt. Der Aufbau der einzelnen Dateien ist bewusst einfach gewählt, da bereits eine hohes Maß an Komplexität in der GUI und dem Datenbanksystem steckt. Darüber hinaus wird somit die Rechenzeit beim Abarbeiten der Skripte möglichst gering gehalten, so müssen, wie bereits erwähnt, die Geometrien nicht von einem in ein anderes Format überführt werden, sondern nur an die Cientanwendung weitergereicht werden.

33 4.3 Webbrowser 27 Die Ebene des Webserver ist dahingehend wichtig, dass ein Webbrowser nicht in der Lage ist eine Verbindung zu einem Datenbankserver aufzubauen. Darüber hinaus ist es in vielen Umgebungen wichtig, dass Nutzer keinen direkten Zugriff auf die Datenbasis besitzen (siehe 3.2 Architektur). 4.3 Webbrowser Wie bereits in X3DOM und in Dojo Toolkit beschrieben, wurden zur Realisierung der Anwendung im Webbrowser X3DOM und das Dojo Toolkit zur Unterstützung genutzt. Dies ermöglicht es bereits nach wenigen Zeilen Code erste Ergebnisse sehen zu können. Darüber hinaus erleichtern solche Bibliotheken die Arbeit mit mehreren Browsern. Das Frontend der Anwendung besteht hauptsächlich aus 3 Dateien: einer HTML Seite, welche das Grundgerüst für die Oberfläche liefert und alle weiteren Inhalte einbettet, einer CSS Datei, welche das Aussehen der einzelnen Elemente näher bestimmt und einer Javascript Datei, welche alle Methoden enthält, damit die Anwendung wie gewünscht funktioniert und auf Nutzereingaben reagiert. Hinzu kommen eine Javascript Datei, welche eine Erweiterung zur Dojo Bibliothek darstellt sowie mehrere Javascript und CSS Dateien, welche mit den Bibliotheken geliefert werden GUI Layout Die Oberfläche ist in drei Hauptbereiche aufgeteilt (siehe Abb. 7 auf S. 28). Das Design ist dabei an viele Modellierungsprogramme wie gocad oder AutoCAD angelehnt. Im oberen Teil des Fensters befinden sich mehrere Buttons, welche verschiedene Interaktionen mit dem Modell beinhalten. Auf der linken Seite wird ein Baum angezeigt, welcher die in der Datenbank verfügbaren Objekte repräsentiert (siehe Checkbox Tree). Die Mitte des Bildschirms wird genutzt um die 3D Objekte darzustellen. Wie in Abb. 7 auf S. 28 zu erkennen ist, gibt es eine weitere Szene an der oberen rechten Ecke, welche ein Koordinatensystem enthält, welches zur groben Orientierung im Raum genutzt werden kann Checkbox Tree Um eine ähnliche Funktionalität, wie beispielsweise in gocad, zu erreichen, nämlich eine Anzeige aller verfügbaren Objekte, welche durch Setzen eines Hakens im Hauptfenster

34 4.3 Webbrowser 28 Abb. 7: Grundsätzliches Oberflächenlayout: Oben Buttons zur Interaktion, links Anzeige der Elemente der Datenbank, rechts Darstellung der 3D Szene. dargestellt werden, wurde das von dijit bereitgestellte Widget Tree dahingehend erweitert, dass es sog. Checkboxen enthält, welche dem Nutzer anzeigen ob ein Objekt ausgewählt bzw. aktiviert wurde. Solche baumartigen Strukturen werden häufig genutzt um Hierarchien darzustellen. So lässt sich ein ähnlicher Baum im Windows Explorer finden. Durch Aufklappen der übergeordneten Elemente, werden die darunter befindlichen Objekte angezeigt. Der hier verwendete Checkbox Tree implementiert folgende Verhalten: wird ein übergeordnetes Element aktiviert, werden alle Kinderelemente ebenfalls aktiviert, sind alle Kinderelemente aktiviert, wird das Elternelement ebenfalls aktiviert, sollte die Eigenschaft constrained gesetzt sein, so kann immer nur ein Kinderelement aktiviert werden (bei Aktivierung eines anderen Elementes wird das vorher aktivierte Element deaktiviert),

35 4.3 Webbrowser 29 bei der Aktivierung bzw. Deaktivierung eines Elements wird das Ereignis onnodechecked bzw. onnodeunchecked ausgelöst. Hinzukommend lassen sich außerdem weitere Verhalten für Standardereignisse wie Doppelklick (dblclick) definieren. In dieser Anwendung wird bei einem Doppelklick auf ein Kinderelement ein Dialog geöffnet, welcher es dem Nutzer erlaubt beispielsweise die Farbe des Objektes zu ändern sowie sofern vorhanden die gespeicherten Eigenschaften anzuschauen (siehe Abb. 8). Abb. 8: Eigenschaftsdialog, der geöffnet wird, wenn ein Element aus dem Baum doppelt angeklickt wird. Zu sehen ist die Eigenschaft strike der Klasse measurements. Das Baum Element hier ist ebenfalls ein Checkbox Tree, aber mit der Eigenschaft verb constrained, d.h. es kann nur eine Eigenschaft zu einem Zeitpunkt aktiviert sein. Wird das Ereignis onnodechecked ausgelöst, reagiert die Anwendung mit dem folgenden Verhalten: Es wird eine Anfrage an die Datenbank über den Webserver geschickt, welche dann das benötigte X3DOM erzeugt und wiederum über den Webserver an den Browser zurück sendet. Dieses XML Fragment wird nach der kompletten Übertragung in die bestehende Hauptszene eingefügt. Hierbei reagiert die Bibliothek von X3DOM auf die Ereignisse, die beim Einfügen durch den Browser ausgelöst werden (DOMNodeInserted).

36 4.3 Webbrowser 30 X3DOM sorgt dafür, dass die neue Geometrie ebenfalls in den Szenegraph eingefügt wird und stellt diese dann im Hauptfenster dar. Sollte das Ereignis onnodeunchecked ausgelöst werden, wird der entsprechende XML Knoten gesucht und aus dem DOM entfernt. Dies löst entsprechend im Browser das Ereignis DOMNodeRemoved aus, worauf wiederum X3DOM mit einer Aktualisierung des Szenegraphen reagiert. Dementsprechend wird diese Geometrie nicht weiter dargestellt Eigenschaftsdialog Im Eigenschaftsdialog (siehe Abb. 8 auf S. 29), welcher durch einen Doppelklick auf ein Objekt im Checkbox Tree geöffnet wird, können, wie der Name bereits sagt, die Eigenschaften der jeweiligen Objekte eingesehen bzw. verändert werden. Dies kann zum einen die Farbe des Objekts sein, aber auch die auf dem Objekt gespeicherten Eigenschaften des Modells. Darüber hinaus lässt sich einstellen, ob eine bestimmte Eigenschaft durch einen Farbverlauf visualisiert werden soll. Der Farbverlauf wird dabei für jede Eigenschaft dynamisch berechnet. Er hängt somit immer auch vom Minimum und Maximum der jeweiligen Eigenschaft ab. In Abb. 9 auf S. 31 wird ein Beispiel gezeigt. Auf der linken Seite des Fensters wird eine ausgewählte, in diesem Beispiel durch Zufallswerte befüllte, Eigenschaft in einem sog. Grid einer tabellenähnlichen Struktur angezeigt. In diesem Grid wird unter der Spalte Index der Index des Punktes oder der Teilzelle angezeigt (siehe 4.1 Datenbank). Die Spalte Value beinhaltet den tatsächlichen Wert des Punktes oder der Teilzelle. Auf der rechten Seite des Bildes wird die Fläche mit den entsprechenden Farbverläufen dargestellt. Um dies zu erreichen wird zweimal interpoliert (siehe Interpolation). Durch ein weiteres Tab kann der Query-Editor geöffnet werden. Dieser erlaubt es dem Nutzer bestimmte Teile des Objekts nach seinen Eigenschaften für die Darstellung auszuwählen. Genauer gesagt werden nur die Teile angezeigt, die eine bestimmte Bedingung erfüllen, beispielsweise das Erreichen eines gewissen Schwellenwertes. Interpolation Die erste Interpolation wird durch die programmierte Anwendung durchgeführt. Die Farbskala wird durch einen Weg durch den Farbwürfel (siehe Abb. 10 auf S. 32), welcher durch die Achsen r, g, b im Intervall [0, 1] [0, 1] [0, 1] aufgespannt wird, beschrieben. Die sog. Regenbogenskala, wie sie hier verwendet wurde, ist also ein Pfad von Blau zu Rot über die Zwischenstufen Cyan, Grün und Gelb. Dem entsprechend gibt es vier Kanten an denen entlang jeweils interpoliert werden kann: von Blau ([r g b] T = [0 0 1] T ) zu Cyan ([r g b] T = [0 1 1] T ),

37 4.3 Webbrowser 31 Abb. 9: Testfläche, die eine Eigenschaft mit zufälligen Werten besitzt. Links ist ein Teil des Eigenschaftsdialogs zu sehen, welcher die Indizes und Werte der einzelnen Vertices anzeigt. Auf der rechten Seite ist die Fläche im Hauptfenster der Anwendung dargestellt. von Cyan ([r g b] T = [0 1 1] T ) zu Grün ([r g b] T = [0 1 0] T ), von Grün ([r g b] T = [0 1 0] T ) zu Gelb ([r g b] T = [1 1 0] T ), von Gelb ([r g b] T = [1 1 0] T ) zu Rot ([r g b] T = [1 0 0] T ). Das bedeutet, dass immer jeweils nur eine Komponente interpoliert wird, während die anderen beiden entweder die Werte 0 oder 1 annehmen. Null bedeutet dabei, dass die Komponente keinen Anteil hat und Eins, dass ihr Anteil 100 % entspricht. Somit können das Minimum bzw. Maximum dem kleinsten bzw. höchsten Wert der Farbskala entsprechen. Liegt ein Eigenschaftswert zwischen den beiden Extrema, wird für ihn ein eigenständiger Farbwert wie folgt berechnet: 1. Initialisiere r, g, b mit 1, 2. Bestimme das Quantil, in dem der Eigenschaftswert liegt (hier 25 % Quantil, 50 % Quantil und 75 % Quantil). Das erste Quantil (0-25 %) entspricht dabei der ersten Kante, das zweite Quantil (25-50 %) der zweiten u.s.w.

38 4.3 Webbrowser Interpoliere die Komponente, die sich entlang der entsprechenden Kante ändert und setze mindestens eine Komponente auf 0[36]. Die Interpolation der einzelnen Komponenten kann dabei einfach linear geschehen. Dieses Abb. 10: Dieser Würfel spannt die Farben Rot, Grün und Blau im dreidimensionalen Raum auf. Jeder Weg durch diesen Würfel entspricht einer Farbskala entlang der interpoliert werden kann. Für die verwendete sog. Regenbogenskala wurde der dick gezeichnete Pfad von Blau über Cyan, Grün, Gelb zu Rot gewählt[36]. Prinzip lässt sich auf jeden Pfad, der in dem Würfel erstellt werden kann, anwenden. Darüber hinaus sind auch Diagonalen möglich, welche dann aber in den einzelnen Schritten eine Interpolation von bis zu drei Komponenten erfordern. Die Anwendung weist jedem Vertex, über den gespeicherten Index und in Abhängigkeit des Eigenschaftswertes, eine Farbe zu. Dazu wird eine sog. Colornode erstellt, also ein XML Knoten, der die Farbkodierungen enthält. Diese Farben werden dann über X3DOM zu dem WebGL Backend weitergegeben. Sollte es sich bei dem Objekt um eine Linie bzw. Linienzug oder Fläche handeln, erfolgt eine weitere Interpolation durch WebGL, um das Objekt mit einem Farbverlauf darzustellen. Query-Editor Der Query-Editor der Anwendung ist recht einfach gehalten. So stehen in Abhängigkeit vom gewählten Objekt die jeweiligen Eigenschaften und sechs Operatoren (=,!=, >, >=, <, <=) zur Auswahl. Einzig der Eigenschaftswert ist durch den Nutzer frei wählbar. Durch einen Klick auf den Button Add Condition wird die erzeugte Bedingung einem weiteren Fenster hinzugefügt. Werden die eingestellten Bedingungen