M A S T E R A R B E I T
Implementierung eines historischen
3D-Weltatlasses auf der Basis von X3D
ausgeführt am Institut für
Softwaretechnik und Interaktive Systeme
Arbeitsgruppe für Interaktive Multimediale Systeme
der Technischen Universität Wien
unter Anleitung von
DI Dr. Christian Breiteneder, Univ. Prof. und
Dr. Horst Eidenberger, ao. Univ. Prof.
durch
Angelika Preißler Bakk.techn.
Leystraße 26/42
A-1200 Wien
Ort, Datum Unterschrift
 
 
Die approbierte Originalversion dieser Diplom-/Masterarbeit ist an der 
Hauptbibliothek der Technischen Universität Wien aufgestellt  
(http://www.ub.tuwien.ac.at). 
 
The approved original version of this diploma or master thesis is available at the 
main library of the Vienna University of Technology   
(http://www.ub.tuwien.ac.at/englweb/). 
 
Die vorliegende Arbeit beschäftigt sich mit der Umsetzung eines historischen
3D-Weltatlasses. Ein wichtiges Prinzip von Web 2.0 ist die aktive Beteiligung von
Benutzern als Produzenten von Inhalten. Wikis sind ein Vertreter des Web 2.0
und stellen genau diese Funktionalität zur Verfügung. Die grafische Visualisierung
erfolgt mittels X3D. Die Datenbasis wird über ein Wiki verwaltet und kann durch
Benutzer erweitert und bearbeitet werden, wobei die geografischen Daten direkt in
den Wikitext als XML eingebettet werden. Anhand von Links, dem Grundelement
von Wikis, werden die geografischen und historischen Strukturierungen vorgenom-
men. Die Transformation von XML zu X3D erfolgt durch XSL. Durch die Offenheit
des Systems und der Verwendung von bekannten Umgebungen wird die Grundlage
für eine umfangreiche Erweiterung der historischen Datenbank geschaffen.
This diploma thesis deals with the realization of a historical 3D-Worldatlas. An
important principle of Web 2.0 is the active attendance of users as producers of
contents. Wikis are a part of Web 2.0 and offer exactly this functionality for users.
Graphical visualization is done by X3D. The database will be administrate by a
wiki and can be extended and arranged whereas the geographical data is directly
embedded in the wiki text. Geographical and the historical structuring will be
resolved by links, the basic elements of wikis. The transformation from XML to
X3D take place by XSL. Because of the openness of the system and the usage from
well known environments, a large expansion of the historical database is given.
Inhaltsverzeichnis
1 Einleitung 1
2 Hintergrund 3
2.1 Extensible 3D - X3D . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1 Virtual Reality Modeling Language - VRML . . . . . . . . . 3
2.1.2 Entwicklung von X3D . . . . . . . . . . . . . . . . . . . . . 5
2.1.3 VRML und X3D im Vergleich . . . . . . . . . . . . . . . . . 7
2.1.4 Architektur und Komponenten von X3D . . . . . . . . . . . 11
2.1.5 X3D-Werkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1.6 X3D-Spezifikation mit Beispielen . . . . . . . . . . . . . . . 16
2.2 Extended Stylesheet Language Transformation - XSLT . . . . . . . 30
2.3 Wikis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.3.1 Wiki-Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.3.2 Anwendungsgebiete . . . . . . . . . . . . . . . . . . . . . . . 36
2.3.3 Funktionalitäten . . . . . . . . . . . . . . . . . . . . . . . . 37
2.4 Grundlagen zu geografischen Daten . . . . . . . . . . . . . . . . . . 39
2.4.1 Grundbegriffe . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.4.2 Formate für Geodaten . . . . . . . . . . . . . . . . . . . . . 43
2.4.3 Geo-Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3 Entwurf des technischen Systems 50
3.1 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.2 Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.2.1 Wiki-Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.2.2 Seitentypen . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.2.3 Linktypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
i
Inhaltsverzeichnis
3.2.4 Integration von zeitlichen Verläufen . . . . . . . . . . . . . . 54
3.3 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.3.1 Wiki-Extension . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.3.2 Wiki-Spezialseite . . . . . . . . . . . . . . . . . . . . . . . . 56
3.3.3 Benutzereingabe . . . . . . . . . . . . . . . . . . . . . . . . 58
3.3.4 Seite anzeigen . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4 Implementierung des technischen Systems 61
4.1 Definition von Geo-Objekten . . . . . . . . . . . . . . . . . . . . . . 61
4.1.1 Punkt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.1.2 Linie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.1.3 Fläche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.2 Integration in MediaWiki-Umgebung . . . . . . . . . . . . . . . . . 64
4.2.1 Wiki-Extension . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.2.2 Wiki-Spezialseite . . . . . . . . . . . . . . . . . . . . . . . . 69
4.3 XSL-Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.3.1 Punkt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.3.2 Linie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.3.3 Fläche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.3.4 Level of Detail . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.4 Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.4.1 X3D-Plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.4.2 Navigationselemente . . . . . . . . . . . . . . . . . . . . . . 79
4.4.3 Suche nach Zeitperioden . . . . . . . . . . . . . . . . . . . . 82
5 Anwendungsbeschreibung 84
5.1 Erstellung von Artikeln . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.1.1 Geo-Definitionsseite . . . . . . . . . . . . . . . . . . . . . . . 85
5.1.2 Geo-Containerseite . . . . . . . . . . . . . . . . . . . . . . . 87
5.1.3 Nicht geografische Seite . . . . . . . . . . . . . . . . . . . . . 90
5.2 Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.2.1 X3D-Plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.2.2 Navigationselemente . . . . . . . . . . . . . . . . . . . . . . 91
ii
Inhaltsverzeichnis
5.2.3 Suche nach Zeitperioden . . . . . . . . . . . . . . . . . . . . 92
5.2.4 Level of Detail . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.3 Technische Voraussetzungen . . . . . . . . . . . . . . . . . . . . . . 95
5.3.1 Anforderungen an die Inbetriebnahme der Applikation am
Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.3.2 Anforderungen an den Client . . . . . . . . . . . . . . . . . 96
6 Schlussfolgerungen 97
Abbildungsverzeichnis 99
Quelltextverzeichnis 101
Literaturverzeichnis 103
iii
1 Einleitung
Der Grundgedanke vom World Wide Web war die einfache Austauschmöglichkeit
von wissenschaftlichen Daten. Das WWW entwickelte sich immer mehr zur Kon-
sumierung von Inhalten und nicht zur Produzierung dieser. Web 2.0 zeigt jedoch
neue Methoden und Ideen, in denen der Inhalt von Benutzern für Benutzer ver-
fasst wird. Auch Wikis folgen diesem Prinzip, sie bieten das technische Umfeld
für die Erstellung von Artikeln. Durch die Verlinkung dieser Beiträge entsteht ein
umfassendes Nachschlagewerk.
Diese Arbeit beschäftigt sich mit der Erstellung einer Applikation, mit der es
möglich ist geografische Daten mit textuellen Annotationen auf einer dreidimensio-
nalen Weltkugel zu visualisieren. Durch das Hinzufügen der zeitlichen Komponente
(von Ereignissen) kann durch Navigationselemente die historische Entwicklung der
Welt verfolgt werden. Die Datenbasis des Systems bildet eine Wiki-Engine, in der
die Eingabe der geografischen Informationen seitens der Benutzer getätigt wird.
Mittels XSL-Transformation werden diese Daten in die 3D-Modellierungssprache
X3D umgewandelt. Die Visualisierung basiert auf den Verlinkungen der einzelnen
Artikel. Es besteht die Möglichkeit verschiedene geografische Objekte (kurz: Geo-
Objekte) wie Punkt, Linie, Fläche zu erstellen und zusätzliches Kartenmaterial zu
integrieren.
Ziel dieser Arbeit ist es, ein technisches System zu schaffen, in das Wiki-Benutzer
die Daten zu diesem historischen 3D-Weltatlas eingeben können. Kapitel 2 gibt ei-
ne detaillierte Übersicht über die Entwicklung und die Spezifikation von X3D.
Des Weiteren wird ein kurzer Überblick über Wikis, XSL-Transformationen und
geografische Daten gegeben. Das Konzept zur Erstellung der Applikation wird in
Kapitel 3 vorgestellt, wobei auf die Anforderungen an das System und deren Ar-
chitektur näher eingegangen wird. Die technische Umsetzung des Entwurfs wird in
Kapitel 4 näher betrachtet. Die verschiedenen Seitentypen, Geo-Objekte und Na-
1
1 Einleitung
vigationselemente werden aufgelistet und deren Realisierung dargestellt. Kapitel 5
beinhaltet eine ausführliche Beschreibung für die Benutzung der Applikation. Es
werden dabei verschiedene Anwendungsmöglichkeiten gezeigt.
Auf eine geschlechtergerechte Sprache wurde zu Gunsten der besseren Lesbarkeit
verzichtet. Bei allen Formulierungen sind sowohl Frauen als auch Männer gemeint.
2
2 Hintergrund
Zur Einführung in die Thematik werden in diesem Kapitel die Grundlagen der
verwendeten Techniken näher beschrieben. Am Beginn werden die Entwicklung
von X3D und ein Vergleich mit dessen Vorläufer VRML dargestellt. Weiters wird
die Architektur und X3D anhand von praktischen Beispielen betrachtet, ergänzt
durch die Auflistung hilfreicher Tools und vorhandener Browser bzw. Plug-ins.
Die Grundlagen einer XSL Transformation, eines Wikis und die Visualisierung
von geografischen Daten sind weitere Schwerpunkte.
2.1 Extensible 3D - X3D
Für die Visualisierung der historischen Daten wird X3D verwendet. In diesem
Kapitel wird näher auf die Entwicklung, Architektur und Spezifikation von X3D
eingegangen. Weiters werden auch verschiedene Werkzeuge vorgestellt, die zur Er-
stellung von X3D-Inhalten dienen.
2.1.1 Virtual Reality Modeling Language - VRML
Bei VRML handelt es sich um ein einfaches Austauschformat für 3D-Objekte und
Welten, in dem grundlegende Elemente wie Geometrien, Materialeigenschaften,
Transformationen, Lichtquellen, Animation, Interaktion und Viewpoints definiert
sind. Weiters kann VRML als 3D-Gegenstück zu HTML betrachtet werden, durch
VRML ist es möglich dreidimensionale Webseiten zu veröffentlichen. [7] In der
VRML-Spezifikation [45] wird am Beginn der Einleitung folgender Verwendungs-
zweck definiert:
The Virtual Reality Modeling Language (VRML) is a file format for
describing interactive 3D objects and worlds. VRML is designed to
3
2 Hintergrund
be used on the Internet, intranets, and local client systems. VRML is
also intended to be a universal interchange format for integrated 3D
graphics and multimedia.
Der Anfang von VRML liegt bei der ersten World Wide Web Konferenz in
Genf im Mai 1994. Dort präsentierten Marc Pesce und Toni Parisi ihren ersten
Prototypen eines 3D-Browsers (Labyrinth). Daraufhin starteten Diskussionen auf
einer Mailing List über eine mögliche Spezifikation für 3D-Darstellung im WWW.
Open Inventor, entwickelt von Silicon Graphics Inc., diente als Vorlage für die
erste VRML-Spezifikation. Grundlegende Elemente von OpenInventor wurden mit
zusätzlichen Features erweitert, die für das World Wide Web notwendig waren.
Bereits im Oktober 1994 wurden Entwürfe von VRML 1.0 auf der zweiten World
Wide Web Konferenz in Chicago vorgestellt und nach weiteren 6 Monaten im April
1995 als Spezifikation verabschiedet. [7] [9]
Nach der Veröffentlichung des VRML 1.0-Standards entstanden neue Diskus-
sionen über die Weiterentwicklung. Die Meinungen teilten sich, einige forderten
eine komplette Überarbeitung, während andere nur zusätzliche Funktionalitäten
verlangten. Nur in einem Punkt waren sich Anwender wie auch Entwickler einig:
es fehlten wichtige Features wie Animation und Interaktion. Daraufhin wurde die
VRML Architecture Group (VAG) gegründet, die die Koordination der Weiterent-
wicklung übernahm. Der Durchbruch erfolgte, als im Herbst 1995 einige Firmen
erste Vorschläge für eine neue Version vorstellten. Es beteiligten sich verschiedene
Unternehmen (Silicon Graphics und Sony, Microsoft, SUN, Apple, IBM) an einer
vom VAG organisierten Abstimmung im WWW, welcher Vorschlag als zukünf-
tiger Standard verwendet werden sollte. Mit großer Mehrheit (über 70%) wurde
Moving Worlds von Silicon Graphics und Sony gewählt, gefolgt von Microsofts
ActiveVRML. VRML 2.0 wurde im August 1996 als neue Spezifikation veröffent-
licht. Das VRML-Konsortium (VRMLC ) wurde kurz nach der Veröffentlichung
von VRML 2.0 gegründet. SUN, SGI, Microsoft sind einige von vielen Mitglie-
dern. Im September 1997 wurde VRML 2.0 nach kleinen Änderungen unter dem
Namen VRML97 als ISO-Standard anerkannt. Die wichtigsten Erneuerungen zu
VRML 1.0 sind die Integration von Ton, Animation, Interaktion, Scripts und dem
EAI (External-Authoring Interface). [7] [9] [17]
4
2 Hintergrund
2.1.2 Entwicklung von X3D
Der Erfolg von VRML97 war sehr gering. Die Gründe dafür lagen in den dama-
ligen Hardware-Limitationen, der teilweisen unterschiedlichen Darstellungen der
gleichen 3D-Szene durch mehrere Browser und der Syntax, die den Benutzer nicht
so geläufig war, wie zum Beispiel HTML. Mit X3D sollten die Schwachstellen
von VRML97 behoben werden und den Anforderungen von 3D Darstellungen im
World Wide Web gerecht werden. [12] [24] Als Basis für X3D wurde XML (Extensi-
ble Markup Language) festgelegt. Durch die Integration von XML erhoffte sich das
Konsortium eine bessere Interaktion mit dem WWW. [5] Das Hauptaugenmerk
bei XML liegt in der Trennung von Inhalt und Form, weiters können Elemente
durch eine entsprechende DTD (Document Type Definition) beschrieben werden.
Diese DTD kann je nach Erweiterung ausgebaut werden. [11] Auf der Webseite
des Web3D-Konsortium wird X3D wie folgt definiert: [47]
X3D is a royalty-free open standards file format and run-time architec-
ture to represent and communicate 3D scenes and objects using XML.
It is an ISO ratified standard that provides a system for the storage,
retrieval and playback of real time graphics content embedded in ap-
plications, all within an open architecture to support a wide array of
domains and user scenarios.
Der Stand der Entwicklung von X3D kann unter [48] eingesehen werden, der
aktuelle ISO-Standard ist. ISO/IEC 19776:2005 X3D unterstützt derzeit 2D- und
3D-Graphik, Animation, Audio, Video, User Interaktion, Navigation, Scripting,
von User definierte Objekte, Netzwerke, CAD-Daten, Physikalische Simulationen
und Echtzeitkommunikation.
Aus dem VRML-Konsortium entstand das Web3D-Konsortium. [11] Dieses be-
steht aus verschiedenen Arbeitsgruppen, die unterschiedliche Themen bearbeiten:
[46]
X3D Earth ist ein System für dreidimensionale Visualisierungen von Informatio-
nen und Objekten in Bezug auf geografische Daten.
X3D Networking befasst sich mit Netzwerkfähigkeiten.
5
2 Hintergrund
User Interface beschäftigt sich mit der Entwicklung von Funktionalitäten im User
Interface Bereich.
CAD entwickelt ein Dateiformat für die Konvertierung von CAD-Daten in ein
offenes Format.
Medical befasst sich mit der Visualisierung der menschlichen Anatomie anhand
verschiedener Eingabedaten.
VizSim beschäftigt sich mit dem Austausch und der Wiederverwendbarkeit von
dreidimensionalen Daten für Simulation und Modellierung.
X3D Conformance Program kümmert sich um die Vergabe des Handelszeichens
von X3D.
Programmable Shaders beschäftigt sich mit der Integrierung von high-level Sha-
ders.
GeoSpatial war für die Darstellung von geografischen Daten zuständig. Diese Ar-
beitsgruppe wurde mittlerweile im X3D Earth integriert.
DIS-XML befasst sich mit der Entwicklung von Distributed Interactive Simulati-
on.
H-Anim entwickelt eine Schnittstelle zwischen Software für die Modellierung und
Tools, die für die Animierung zuständig sind.
X3D Source beschäftigt sich mit der Weiterentwicklung der X3D-Spezifikation.
Durch den Einsatz von XML, anstelle des Formats von VRML, besteht ein größe-
rer Leistungsumfang durch die Verwendung der vorhandenen Standards und Tools
von XML. Weiters verfügen die meisten Benutzer über günstige und leistungsstar-
ke Grafikkarten, die eine optimale Visualisierung ermöglichen. Daraus ergeben sich
gute Chancen, dass X3D erfolgreicher wird als VRML.
6
2 Hintergrund
Abbildung 2.1: Zeigt die entsprechende Visualisierung zu den Codebeispielen in
VRML und X3D.
2.1.3 VRML und X3D im Vergleich
Die in VRML beschriebenen 3D-Objekte werden in einer hierarchischen Struktur
(Szenegraph) organisiert. Dieser Szenegraph kann sich aus verschiedenen Knoten
zusammensetzen, zum Beispiel Shapes, Geometry, Appearance, Material, Anima-
tion, ... . Die Eigenschaften eines Knoten werden in Datenfeldern definiert. Jedes
dieser Felder ist von einem bestimmten Datentyp, zum Beispiel SFFloat oder SF-
String. [6] [18]
Quelltext 2.1 zeigt ein Beispiel einer einfachen VRML-Szene. [6] Der Group-
Knoten ist der Wurzelknoten und beinhaltet zwei Transform-Knoten (Codezeile
4 und 17 ). Im 1. Knoten erfolgt eine Verschiebung der definierten Sphere (Code-
zeile 8 ) durch das Feld translation an die Position (4 0 0). Diese Translation hat
jedoch keine Auswirkung auf den 2. Knoten, in dem eine Box (Codezeile 22 ) defi-
niert ist. In diesem Knoten erfolgen eine Verschiebung (durch translation) und eine
Rotation (durch rotation). Jedem dieser Transform-Knoten ist ein Shape-Knoten
untergeordnet. Die Felder geometry und appearance sind den Knoten Sphere bzw.
Appearance zugeteilt, letzterer beinhaltet einen weiteren Knoten Material. Durch
die Definition der Felder radius (Codezeile 9 ), size (Codezeile 23 ) und diffuseCo-
lor (Codezeile 13 und 27 ) werden der Radius der Kugel, die Größe der Box und
die Farben der Objekte bestimmt. In Abbildung 2.1 wird das zuvor beschriebene
Beispiel dargestellt.
7
2 Hintergrund
1 #VRML V2.0 ut f8
2 Group {
3 ch i l d r en [
4 Transform {
5 t r a n s l a t i o n 4 0 0
6 ch i l d r en [
7 Shape {
8 geometry Sphere {
9 rad iu s 3 .0
10 }
11 appearance Appearance {
12 mate r i a l Mater ia l {
13 d i f f u s eCo l o r 1 0 0
14 }}}
15 ]
16 }
17 Transform {
18 r o t a t i on 0 1 0 45
19 t r a n s l a t i o n −3 0 0
20 ch i l d r en [
21 Shape {
22 geometry Box {
23 s i z e 5 3 5
24 }
25 appearance Appearance {
26 mate r i a l Mater ia l {
27 d i f f u s eCo l o r 0 0 1
28 }}}
29 ]
30 }
31 ]
32 }
Quelltext 2.1: VRML-Codebeispiel.
8
2 Hintergrund
Quelltext 2.2 zeigt dasselbe Beispiel (Quelltext 2.1 bzw. Abbildung 2.1) in X3D.
Im Gegensatz zu VRML wird jeder Knoten als Element dargestellt und beinahe
jedes Datenfeld als Attribut übernommen. [18] Am Beginn des X3D-Dokuments
stehen die XML-Deklaration (Codezeile 1 ) und eine optionale Document Type De-
finition (Codezeile 2 ). In Codezeile 3 wird das Element X3D mit dessen Attributen
beschrieben, wobei ein entsprechendes XML-Schema und im Attribut profile eines
der Profile angegeben wird. Anschließend wird das Element head definiert, indem
verschiedene Metadaten (Codezeile 5-7 ) angeführt werden können. Wie zum Bei-
spiel der Dateiname, Beschreibung der Datei und Autor. [13] Im Element Scene
(Codezeile 9-28 ) erfolgt die eigentliche Definition der Darstellung. Wie im Beispiel
zuvor sind dem Element Group zwei Transform-Elemente (Codezeile 11 und 19 )
untergeordnet, mit den Attributen translation und rotation wird die Translation
und die Rotation definiert. Jedem Transform-Element sind je ein Shape-Element
(Codezeile 12 und 20 ) untergeordnet, in denen sind weiters Appearance-Elemente
(Codezeile 14 und 22 ) und einmal ein Sphere-Elemente (Codezeile 13 ) und ein
Box -Elemente (Codezeile 21 ) zugeordnet. Den Appearance-Elementen sind dann
je ein Material -Element (Codezeile 15 und 23 ) zugeteilt.
In der Spezifikation [51] werden Elemente aber weiterhin als Knoten bezeichnet
und Attribute als Datenfelder. [18] Sowohl VRML als auch X3D basieren auf ei-
nem Szenegraph, siehe Abbildung 2.2, und beide benötigen einen eigenen Browser
oder ein Browser-Plug-in für die Darstellung der 3D-Szene. Aufgrund der Syntax
von XML bietet X3D eine kompaktere Schreibweise als VRML, das wegen der
teilweisen tiefen Verschachtelungen nicht sehr gut lesbar ist. Ein weiterer Vorteil
von X3D ist die sofortige Überprüfung der Gültigkeit des Dokuments durch die
Validierung mit einer DTD. [18]
9
2 Hintergrund
1 <?xml ve r s i on =”1.0” encoding=”UTF−8”?>
2 <!DOCTYPE X3D PUBLIC ”http ://www. web3d . org / s p e c i f i c a t i o n s /
x3d−3.1. dtd” ” f i l e : ///www. web3d . org /TaskGroups/x3d/
t r a n s l a t i o n /x3d−3.1. dtd”>
3 <X3D p r o f i l e=”Immersive” ve r s i on =”3.0” xmlns : xsd=”http ://
www.w3 . org /2001/XMLSchema−i n s t anc e ” xsd :
noNamespaceSchemaLocation=”http ://www. web3d . org /
s p e c i f i c a t i o n s /x3d−3.1. xsd”>
4 <head>
5 <meta content=”blueBoxRedSphere . x3d” name=”f i l ename”/>
6 <meta content=”s imple X3D example” name=”de s c r i p t i o n ”/>
7 <meta content=”Angel ika P r e i s s l e r ” name=”c r e a t o r ”/>
8 </head>
9 <Scene>
10 <Group>
11 <Transform t r a n s l a t i o n=”4 0 0”>
12 <Shape>
13 <Sphere rad iu s =”3.0”/>
14 <Appearance>
15 <Mater ia l d i f f u s eCo l o r=”1 0 0”/>
16 </Appearance>
17 </Shape>
18 </Transform>
19 <Transform ro t a t i on=”0 1 0 45” t r a n s l a t i o n=”−3 0 0”>
20 <Shape>
21 <Box s i z e =”5 3 5”/>
22 <Appearance>
23 <Mater ia l d i f f u s eCo l o r=”0 0 1”/>
24 </Appearance>
25 </Shape>
26 </Transform>
27 </Group>
28 </Scene>
29 </X3D>
Quelltext 2.2: X3D-Codebeispiel.
10
2 Hintergrund
Abbildung 2.2: Zeigt den dazugehörigen Szenegraph zu den Codebeispielen in
VRML und X3D.
2.1.4 Architektur und Komponenten von X3D
Jede X3D-Applikation beinhaltet grafische und akustische Objekte. Diese wer-
den über ein Netzwerk geladen und können dynamisch modifiziert werden. Die
X3D Semantik beschreibt eine abstrakte funktionale Verhaltensweise von inter-
aktiven, auf Zeit basierenden 3D-Informationen. In Abbildung 2.3 wird die X3D-
Architektur dargestellt. X3D definiert keine physikalischen Geräte oder andere
Konzepte, die von Implementationen abhängig wären, wie Eingabegeräte und Bild-
schirmauflösung. Das heißt, es wird zum Beispiel die Existenz einer Maus nicht vor-
ausgesetzt. Durch X3D kann die Verhaltensweise von Objekten definiert werden
und es bietet die Möglichkeit, eine Verbindung zu externen Applikationen mittels
Programmier- und Scriptsprachen zu erstellen, siehe Spezifikation. [51] [13]
Im Gegensatz zu VRML ist der Aufbau von X3D modular. Die Spezifikation
von X3D besteht aus 24 Komponenten, die verwandte Funktionalitäten zusam-
menfassen. Jede Komponente ist weiters durch Ebenen unterteilt. Mit Hilfe der
Ebenen wird definiert, inwieweit eine Komponente unterstützt wird. Bestehende
Komponenten können durch Hinzufügen von neuen Ebenen modifiziert oder er-
weitert werden bzw. können durch die Erweiterung von neuen Fähigkeiten neue
Komponenten generiert werden. [13] [47] [18]
Tabelle 2.1 stellt die Komponente Geometry3D und ihre 4 Ebenen dar. In der
ersten Ebene sind die Grundelemente spezifiziert, wie Box, Kegel, Zylinder und
Kugel. Ebene 2 definiert alle Knoten der Ebene 1 und zusätzlich einen neuen
Knoten IndexedFaceSet. Ebene 3 beinhaltet neben den Knoten von Ebene 1 und 2
11
2 Hintergrund
Abbildung 2.3: X3D-Architektur. [51]
Ebene Knoten/Features
1 Box, Cone, Cylinder, Sphere
2 Alle Geometrie-Knoten von Ebene 1 + IndexedFaceSet
3 Alle Geometrie-Knoten von Ebene 2 + ElevationGrid
4 Alle Geometrie-Knoten von Ebene 3 + Extrusion
Tabelle 2.1: Geometry3D Komponente und die dazugehörigen Ebenen.
den Knoten ElevationGrid und in Ebene 4 wird der Knoten Extrusion hinzugefügt.
[51] [18]
Aus den bestehenden Komponenten werden Profile zusammengestellt. Es wird
zwischen sechs Profilen unterschieden. Diese sind unterteilt in vier Basis-Profile,
siehe Abbildung 2.4: [47]
Interchange definiert die Kommunikation zwischen den Applikationen. Geome-
trie, Texturierung, grundlegende Beleuchtung und Animation werden in die-
sem Profil unterstützt.
Interactive ermöglicht ein Navigieren des Benutzers und somit eine Interaktion
12
2 Hintergrund
Abbildung 2.4: Die vier Basis-Profile.
mit einer 3D-Umgebung durch Hinzufügen von verschiedenen Sensoren (z.B.
TouchSensor). Weiters bietet dieses Profil zusätzliche Beleuchtungsmöglich-
keiten und eine erweiterte Zeitsteuerung.
Immersive bietet sowohl Unterstützung für Audio, Nebel, Kollision, Interaktion
als auch eine vollständige 3D Graphik.
Full beinhaltet die Implementierung aller Knoten, inklusive GeoSpatial, NURBS,
H-Anim.
und zwei zusätzlichen Profilen:
MPEG-4 Interactive unterstützt Broadcasting und Mobilgeräte.
CDF (CAD Distillation Format) befindet sich noch in der Entwicklung. Gedacht
ist dieses Profil für die Übersetzung von CAD-Daten in ein offenes Format.
Der Vorteil dieser modularen Architektur ist die Möglichkeit neue Komponenten
zu integrieren, ohne damit die gesamte Spezifikation zu beeinträchtigen. [47] X3D
ist dadurch wesentlich einfacher zu erweitern als VRML97. Bei der Anwendung
müssen nicht alle vorhandenen Funktionalitäten verwendet werden. Durch den
Einsatz von Profilen, Komponenten und Ebenen lassen sich, je nach Bedarf, jeweils
die erforderlichen Features einbinden.
13
2 Hintergrund
2.1.5 X3D-Werkzeuge
Die Erstellung von dreidimensionalen Inhalten in X3D wird durch eine Vielzahl
von Tools unterstützt. Diese reichen von speziellen Editoren, Browsern, Plug-ins
bis zu Export-Plug-ins für Modellierungs-Software. [52]
Editor
X3D-Edit [49] ist ein Editor mit grafischer Benutzeroberfläche. Durch diesen X3D-
Editor ist es möglich, ein X3D-Dokument sehr einfach zu erstellen und gleichzeitig
auch das Dokument zu validieren. Zusätzlich werden Tooltips angeboten, die für
jeden Knoten eine kompakte Zusammenfassung bieten und somit sowohl Anfänger
als auch fortgeschrittene Anwender unterstützen. X3D-Edit basiert auf Java und
Xeena, einem XML-Editor von IMB. [13]
Im Hauptfenster wird das X3D-Dokument in Form eines Szenegraphs darge-
stellt. Links davon werden sämtliche Knoten aufgelistet, die X3D zu Verfügung
stellt. Je nachdem welches Profil selektiert wurde, sind die entsprechenden Knoten
aktiviert oder deaktiviert. Nach Auswahl eines Knotens werden links unten die
jeweiligen Attribute des Knoten eingeblendet. Zusätzliche Funktionalitäten bietet
X3D-Edit mit der Konvertierung von X3D in ein anderes Format mittels XSLT,
z.B.: VRML, HTML und die Möglichkeit ein X3D-Dokument in der XML-Syntax
zu betrachten. Es wird jedoch keine direkte Modifizierung der XML Elemente an-
geboten. Vorteile von X3D-Edit sind die einfache Erstellung von Szenen, sowie die
Plattformunabhängigkeit durch die Verwendung von Java.
Browser bzw. Plug-ins
Um eine 3D-Welt in X3D darstellen zu können, ist entweder ein Browser wie Xj3D
oder ein Plug-in für einen Webbrowser erforderlich. Eine Auflistung von möglichen
Browsern und Plug-ins ist unter [52] zu finden.
Die Firma Bitmanagement Software GmbH bietet die Plug-ins BS Contact VRM-
L/X3D 7.0 und BS Contact Geo an. Im BS Contact Geo wird neben den Funktio-
nalitäten von BS Contact VRML/X3D 7.0 noch zusätzlich die Geospatial -Kompo-
nente von X3D teilweise unterstützt. Bei beiden Plug-ins handelt es sich um kom-
merzielle Produkte, es werden aber kostenlose Testversionen angeboten. [4]
14
2 Hintergrund
OS Browser
Software Type
Win Linux Mac IE Firefox
X3D
Cortona P X X X X
Octaga Player P,S X X X X X
Flux Player P,S,T X X X X
BS Contact P X X X X
blaxxun Contact P X X
Cosmo Player P X X
FreeWRL P,S,T X X X X
OpenVRML P,S,T X X X X X
Xj3D S,T X X X X
Carina S X X X X
Demotride S X X
blaxxun3D A X X X X X
Typen: P=Plug-in, S=standalone Programm, T=Toolkit, A=Applet
Tabelle 2.2: Übersicht von X3D-Plug-ins, Applets, Toolkits und Browser. [35]
Der Flux Player 2.0 wird von der Firma Media Machines entwickelt. Es handelt
sich hier ebenfalls um ein Plug-in für Webbrowser. Im Flux Player werden die
X3D-Szenen durch ActiveX control geladen, die Verbindung zu Elementen anderer
Webseiten erfolgt mittels XML/DOM. [25] [52]
Xj3D ist eine Referenzimplementierung des Web3D-Konsortiums. Die Idee war
ein Toolkit für X3D und VRML97 in Java zu implementieren. In diesem Toolkit
ist auch ein eigener Viewer enthalten. [53] [52] Die Hauptziele für die Entwicklung
von Xj3D waren: [23]
- die Entdeckung und Identifizierung von Problemen bei der Entwicklung der
X3D-Spezifikation
- eine Plattform für die Weiterentwicklung zu bieten
- zu zeigen, dass alle Komponenten der Spezifikation in einem Browser imple-
mentiert werden können.
Tabelle 2.2 zeigt eine Übersicht verschiedener X3D-Plug-ins, Applets, Toolkits
und Browser.
15
2 Hintergrund
2.1.6 X3D-Spezifikation mit Beispielen
X3D verwendet ein kartesisches, rechtshändiges, dreidimensionales Koordinaten-
system. Der Betrachter blickt von der z-Achse in Richtung Ursprung, der negativen
z-Achse entgegen. Die y-Achse zeigt nach oben und die x-Achse nach rechts. Das
Längenmaß des Weltkoordinatensystems ist Meter, Winkel werden im Bogenmaß
und die Zeit in Sekunden angegeben. Als Farbraum wird das RGB-Farbsystem
(Rot, Grün, Blau) verwendet. [51]
In den nachfolgenden Punkten werden einige X3D-Knoten näher betrachtet. Die
verwendete Spezifikation kann unter [51] nach gelesen werden.
3D-Objekte
Ein Objekt, oder eine Welt, wird zumeist im Knoten Shape beschrieben. Dieser
besteht aus einer Verknüpfung eines Geometrie- und Appearance-Knotens, welche
die Form und das Aussehen beschreiben. Mittels des Knotens Geometrie lassen
sich zweidimensionale Objekte, grundlegende dreidimensionale Objekte (Box, Co-
ne, Cylinder, Sphere) und komplexere 3D-Objekte (ElevationGrid, IndexedFaceSet,
NURBS ) definieren. Alle dreidimensionalen Geometrie-Knoten beinhalten das Da-
tenfeld solid. Durch dieses Feld wird bestimmt ob eine Geometrie sichtbar ist, wenn
sich die Position des Betrachters innerhalb der Geometrie befindet.
Der Knoten Box, siehe Quelltext 2.3, definiert einen Quader. Mit dem Feld size
wird die Größe bestimmt. Das Beispiel wird in Abbildung 2.5 dargestellt.
16
2 Hintergrund
Abbildung 2.5: Zeigt die entsprechende Visualisierung der Box.
Box : X3DGeometryNode {
SFNode [ in , out ] metadata NULL [ X3DMetadataObject ]
SFVec3f [ ] s i z e 2 2 2 (0 , i n f i n i t e )
SFBool [ ] s o l i d TRUE
}
Be i s p i e l :
<Scene>
<Shape>
<Box s i z e =”4 2 3”/>
</Shape>
</Scene>
Quelltext 2.3: Spezifikation des Knotens Box mit Beispiel.
Der Knoten Cone, siehe Quelltext 2.4, definiert einen Kegel. Mit dem Feld bot-
tomRadius wird der Radius der Grundfläche, mit height die Höhe des Kegels be-
stimmt. Über side und bottom kann definiert werden, ob der Mantel bzw. die
Grundfläche sichtbar sein sollen. In Abbildung 2.6 wird die Visualisierung des Bei-
spiels gezeigt.
17
2 Hintergrund
Abbildung 2.6: Zeigt die entsprechende Visualisierung des Kegels.
Cone : X3DGeometryNode {
SFNode [ in , out ] metadata NULL [ X3DMetadataObject ]
SFBool [ ] bottom TRUE
SFFloat [ ] bottomRadius 1 (0 , i n f i n i t e )
SFFloat [ ] he ight 2 (0 , i n f i n i t e )
SFBool [ ] s i d e TRUE
SFBool [ ] s o l i d TRUE
}
Be i s p i e l :
<Scene>
<Shape>
<Cone bottomRadius=”2” he ight=”3”/>
</Shape>
</Scene>
Quelltext 2.4: Spezifikation des Knotens Cone mit Beispiel.
Der Knoten Cylinder, siehe Quelltext 2.5, definiert einen Zylinder. Mit dem
Feld radius wird der Radius und mit height die Höhe des Zylinders bestimmt. Der
Zylinder besteht aus drei Teilen: top, side und bottom. Über den entsprechenden
Feldern kann definiert werden, ob der Mantel, bzw. die obere, oder die untere
18
2 Hintergrund
Grundfläche sichtbar sein sollen. Das Beispiel des Zylinders wird in Abbildung 2.7
visualisiert.
Cyl inder : X3DGeometryNode {
SFNode [ in , out ] metadata NULL [ X3DMetadataObject ]
SFBool [ ] bottom TRUE
SFFloat [ ] he ight 2 (0 , i n f i n i t e )
SFFloat [ ] r ad iu s 1 (0 , i n f i n i t e )
SFBool [ ] s i d e TRUE
SFBool [ ] s o l i d TRUE
SFBool [ ] top TRUE
}
Be i s p i e l :
<Scene>
<Shape>
<Cyl inder he ight =”2.5” rad iu s=”1”/>
</Shape>
</Scene>
Quelltext 2.5: Spezifikation des Knotens Cylinder mit Beispiel.
Der Knoten Sphere, siehe Quelltext 2.6, definiert eine Kugel. Mit dem Feld
radius wird der Radius der Kugel bestimmt. Das Beispiel wird in Abbildung 2.8
dargestellt.
19
2 Hintergrund
Abbildung 2.7: Zeigt die entsprechende Visualisierung des Zylinders.
Sphere : X3DGeometryNode {
SFNode [ in , out ] metadata NULL [ X3DMetadataObject ]
SFFloat [ ] r ad iu s 1 (0 , i n f i n i t e )
SFBool [ ] s o l i d TRUE
}
Be i s p i e l :
<Scene>
<Shape>
<Sphere rad iu s =”3.0”/>
</Shape>
</Scene>
Quelltext 2.6: Spezifikation des Knotens Sphere mit Beispiel.
Über den Knoten ElevationGrid lässt sich ein einheitliches Gitter mit unter-
schiedlichen Höhen definieren. Es ist sehr gut geeignet für die Gestaltung von
Terrains.
Der Knoten IndexedFaceSet definiert einen dreidimensionalen Körper, der aus
einzelnen Flächen konstruiert ist. Diese Flächen sind wiederum aus einer Menge
von Punkten zusammengesetzt. Mittels IndexedFaceSet ist es mögliche freie drei-
dimensionale Formen darzustellen. [1]
20
2 Hintergrund
Abbildung 2.8: Zeigt die entsprechende Visualisierung der Kugel.
Material und Beleuchtung
Mittels des Appearance-Knotens wird das Aussehen eines Objektes beschrieben.
Mit den untergeordneten Knoten Material und ImageTexture lassen sich die Ober-
flächeneigenschaft und die Texturierung eines Objektes definieren.
Der Knoten Material, siehe Quelltext 2.7, spezifiziert Materialeigenschaften.
Zum Beispiel definiert das diffuseColor -Feld die Farbe des Objektes und trans-
parency bestimmt, wie transparent ein Objekt ist. Der Wert 1 bedeutet komplett
transparent und 0 vollkommen undurchsichtig. In Abbildung 2.9 wird das Beispiel
dargestellt.
21
2 Hintergrund
Mater ia l : X3DMaterialNode {
SFFloat [ in , out ] ambient Intens i ty 0 .2 [ 0 , 1 ]
SFColor [ in , out ] d i f f u s eCo l o r 0 . 8 0 .8 0 .8 [ 0 , 1 ]
SFColor [ in , out ] emi s s iveCo lo r 0 0 0 [ 0 , 1 ]
SFNode [ in , out ] metadata NULL [
X3DMetadataObject ]
SFFloat [ in , out ] s h i n i n e s s 0 . 2 [ 0 , 1 ]
SFColor [ in , out ] specu la rCo lo r 0 0 0 [ 0 , 1 ]
SFFloat [ in , out ] t ransparency 0 [ 0 , 1 ]
}
Be i s p i e l :
<Scene>
<Shape>
<Sphere rad iu s=”3”/>
<Appearance>
<Mater ia l d i f f u s eCo l o r=”0 1 0”/>
</Appearance>
</Shape>
</Scene>
Quelltext 2.7: Spezifikation des Knotens Material mit Beispiel.
Durch den ImageTexture-Knoten, siehe Quelltext 2.8, ist es möglich, eine Textur
auf eine Geometrie abzubilden. Die Textur wird definiert durch die Angabe eines
Pfades (url) zu einem Bild. Das Beispiel wird in Abbildung 2.10 dargestellt.
22
2 Hintergrund
Abbildung 2.9: Zeigt die entsprechende Visualisierung des Material-Knotens.
ImageTexture : X3DTexture2DNode {
SFNode [ in , out ] metadata NULL [ X3DMetadataObject ]
MFString [ in , out ] u r l [ ] [ urn ]
SFBool [ ] repeatS TRUE
SFBool [ ] repeatT TRUE
SFNode [ ] t e x tu r eP rope r t i e s NULL [
TextureProper t i e s ]
}
Be i s p i e l :
<Scene>
<Shape>
<Sphere rad iu s =”3.0”/>
<Appearance>
<ImageTexture u r l=”earth . jpg”/>
</Appearance>
</Shape>
</Scene>
Quelltext 2.8: Spezifikation des Knotens ImageTexture mit Beispiel.
Durch die Knoten DirectionalLight, PointLight und SpotLight spezifiziert X3D
23
2 Hintergrund
Abbildung 2.10: Zeigt die entsprechende Visualisierung des ImageTexture-
Knotens.
unterschiedliche Möglichkeiten zur Beleuchtung. Für nähere Details siehe [51].
Transformation
Der Knoten Transform, siehe Quelltext 2.9, gehört zum Group-Knoten und defi-
niert für seine Unterknoten ein Koordinatensystem, relativ zum Koordinatensys-
tem des übergeordneten Knotens. Mittels der Datenfelder translation, rotation und
scale sind eine Rotation, Verschiebung und Skalierung spezifiziert. Die Verschie-
bung ist definiert durch einen dreidimensionalen Vektor, der das Objekt entlang
der x-, y- und z-Achse verschiebt. Bei der rotation bestimmen die ersten drei Wer-
te die Rotationsachse und der vierte Wert den Rotationswinkel. Bei scale erfolgt
durch die Angabe eines dreidimensionalen Vektors eine Skalierung entlang der x-,
y- und z-Achse. Werden drei gleiche Werte verwendet, bleibt die Proportion des
Objektes erhalten. [24] In Abbildung 2.11 wird das Beispiel zur Transformation
dargestellt.
24
2 Hintergrund
Transform : X3DGroupingNode {
MFNode [ in ] addChildren [ X3DChildNode ]
MFNode [ in ] removeChildren [ X3DChildNode ]
SFVec3f [ in , out ] c en t e r 0 0 0 (− i n f , i n f )
MFNode [ in , out ] c h i l d r en [ ] [ X3DChildNode ]
SFNode [ in , out ] metadata NULL [
X3DMetadataObject ]
SFRotation [ in , out ] r o t a t i on 0 0 1 0 [−1 ,1] or
(− i n f , i n f )
SFVec3f [ in , out ] s c a l e 1 1 1 (− i n f , i n f )
SFRotation [ in , out ] s c a l eOr i e n t a t i on 0 0 1 0 [−1 ,1] or
(− i n f , i n f )
SFVec3f [ in , out ] t r a n s l a t i o n 0 0 0 (− i n f , i n f )
SFVec3f [ ] bboxCenter 0 0 0 (− i n f , i n f )
SFVec3f [ ] bboxSize −1 −1 −1 [ 0 , i n f ) or
−1 −1 −1
}
Be i s p i e l :
<Scene>
<Shape>
<Box/>
<Appearance>
<Mater ia l d i f f u s eCo l o r=”1 0 0”/>
</Appearance>
</Shape>
<Transform s c a l e =”1.8 1 .8 1 .8” t r a n s l a t i o n=”−4 0 0”>
<Shape>
<Sphere/>
<Appearance>
<Mater ia l d i f f u s eCo l o r=”0 1 0”/>
</Appearance>
</Shape>
</Transform>
25
2 Hintergrund
Abbildung 2.11: Zeigt die entsprechende Visualisierung des Transform-Knotens.
<Transform ro t a t i on=”0 0 1 3.1415 ” t r a n s l a t i o n=”−2 4 0”>
<Shape>
<Cone bottomRadius=”1” he ight=”2”/>
<Appearance>
<Mater ia l d i f f u s eCo l o r=”0 0 1”/>
</Appearance>
</Shape>
</Transform>
</Scene>
Quelltext 2.9: Spezifikation des Knotens Transform mit Beispiel.
Navigation
Der Knoten Navigationinfo definiert die Möglichkeiten, die sich dem Benutzer bei
der Navigation bieten. Es werden unterschiedliche Arten von Navigation angebo-
ten: ANY, WALK, EXAMINE, FLY, LOOKAT, und NONE, wobei die Kombina-
tion aus EXAMINE ANY FLY die beste Einstellung bietet.
Durch den Viewpoint-Knoten können vordefinierte Standpunkte erstellt werden,
die dem Benutzer eine sehr schnelle und angenehme Navigation durch eine Welt
ermöglichen. [13]
26
2 Hintergrund
Mit dem LOD-Knoten können von einem Objekt unterschiedlich detaillierte Ver-
sionen definiert werden. Je nach Abstand vom Benutzer zum Objekt werden die
verschiedenen Varianten eines Gegenstandes eingeblendet. Diese werden innerhalb
von LOD aufgelistet. Die Angabe der Objekte erfolgt von sehr detaillierter bis we-
niger detaillierter Darstellung. Mit dem Attribut range wird die Distanz definiert,
in der der Wechsel zwischen den unterschiedlichen Detaillierungsgraden erfolgt,
siehe Quelltext 2.10.
LOD : X3DGroupingNode {
MFNode [ in ] addChildren [ X3DChildNode ]
MFNode [ in ] removeChildren [ X3DChildNode ]
MFNode [ in , out ] c h i l d r en [ ] [ X3DChildNode ]
SFNode [ in , out ] metadata NULL [ X3DMetadataObject ]
SFVec3f [ ] bboxCenter 0 0 0 (− i n f , i n f )
SFVec3f [ ] bboxSize −1 −1 −1 [ 0 , i n f ) or −1 −1 −1
SFVec3f [ ] c en t e r 0 0 0 (− i n f , i n f )
MFFloat [ ] range [ ] [ 0 , i n f ) or −1
}
Quelltext 2.10: Spezifikation des Knotens LOD.
X3D Event Model
Eine dreidimensionale Szene kann auf unterschiedliche Art und Weise beeinflusst
werden. Entweder durch die Interaktion eines Benutzers mit der 3D-Welt (wird
registriert durch Sensoren) oder durch vordefinierte, Zeit gesteuerte Aktionen (In-
terpolatoren). Als Basis dient das X3D Event Model, indem eine Nachricht von ei-
nem Knoten zu einem anderen Knoten gesendet wird. Realisiert wird dieses Prinzip
durch ROUTEs. Mit einer ROUTE ist es möglich Verbindungen zwischen Kno-
ten herzustellen. So kann ein Event vom Datenfeld eines Knotens zum Datenfeld
eines anderen Zielknotens geschickt werden, womit sich der Zustand des Knotens
ändert. X3D spezifiziert vier Zugriffsarten auf die Datenfelder eines Knotens:
initializeOnly der Wert eines Datenfeldes kann zur Laufzeit nicht geändert werden.
27
2 Hintergrund
inputOnly der Empfang eines Events ist möglich, jedoch sind keine Leserechte
vergeben.
outputOnly das Senden eines Events ist möglich, jedoch sind keine Schreibrechte
vergeben.
inputOutput sowohl der Empfang als auch das Senden von Events ist möglich.
Das ROUTE Statement, siehe Quelltext 2.11, kann überall im X3D-Dokument
definiert werden. Das Feld <fromNodeName> gibt den Namen des Knotens an,
der einen Event generiert und <fromFieldName> den Namen des Datenfeldes.
Dieses Feld beinhaltet den zu übermittelten Wert. Mit <toNodeName> und <to-
FieldName> werden der Knoten, der den Event erhält, und das entsprechende
Datenfeld spezifiziert. [13] [18]
ROUTE <fromNodeName> <fromFieldName> <toNodeName>
<toFieldName>
Quelltext 2.11: Spezifikation von ROUTE.
Durch Sensoren werden Aktionen registriert, die von Benutzern getätigt wer-
den. [18] Die Übermittlung der Werte erfolgt über eine ROUTE. In X3D werden
verschiedene Typen von Sensoren spezifiziert: Pointing device sensors, Key device
senors, Environmental sensor und Picking sensor component. Mittels TimeSen-
sor ist es möglich periodische Aktivitäten, Animationen oder auf Zeit basierende
Events zu kontrollieren. So kann über diesen Sensor ein Zeitintervall in einer Schlei-
fe wiederholt, gestoppt oder gestartet werden. [5] Die Position und den Zustand
eines pointing devices (z.B. Maus) wird durch den TouchSensor getrackt, dieser
lokalisiert ob der Betrachter auf ein Objekt zeigt. Dem Datenfeld isOver wird der
Wert TRUE zugewiesen, wenn auf ein Objekt mittels Eingabegerät gezeigt wird.
Der Zustand wird auf FALSE gesetzt, wenn sich die Maus wieder vom Objekt
wegbewegt.
Mit Interpolatoren ist es möglich Zeit gesteuerte Animationen zu erhalten. Durch
die Interpolation von vordefinierten Schlüsselwerten (key values) werden die erfor-
derlichen Zwischenwerte berechnet. [24] X3D spezifiziert verschiedene Interpolato-
ren, zum Beispiel ColorInterpolator, OrientationInterpolator, PositionInterpolator.
28
2 Hintergrund
Um eine Rotation zu erzeugen, wird der Knoten OrientationInterpolator verwen-
det. Die Interpolation erfolgt durch die Berechnung des kürzesten Wegs zwischen
den Werten. Der PositionInterpolator wird verwendet, um Positionen innerhalb
einer Animation zu berechnen.
Durch den Knoten Script ist die Einbindung von Programmen möglich, die in
einer anderen Programmiersprache geschrieben wurden. [24] Dabei kann der Pro-
grammteil direkt im X3D-Dokument integriert werden oder extern in einer Datei.
[18] Mit SAI (Scene access interface) wird ein Programm Interface angeboten, das
den Zugriff auf den Szenegraphen zur Laufzeit ermöglicht. SAI bietet eine API für
interne Skripts und externe Programme. [50]
Geospatial
Die Komponente Geospatial bietet Unterstützung für die Darstellung von geogra-
fischen Daten mit Bezug auf andere Informationen. X3D unterstützt hier unter
anderem die Angabe von Koordinaten oder die Modellierung von Terrains.
Mit GeoCoordinate ist die Definition von Koordinaten möglich, die im Feld coord
von Knoten, wie IndexedFaceSet, IndexLineSet und PointSet, verwendet werden.
Mittels geoSystem wird ein räumliches Bezugssystem definiert, wie GD - Geodetic
spatial reference frame (latitude/longitude), UTM - Universal Transverse Merca-
tor, GC - Earth-fixed Geocentric. Durch GeoElevationGrid ist die Spezifizierung
eines einheitlichen Gitters von Höhenwerten gegeben. Diese Werte werden in eine
geozentrische, gekrümmte Darstellung der Erde umgewandelt. Damit ist es möglich
Koordinaten durch Breitengrad, Längengrad und durch Höhe darzustellen. Die
Positionierung eines Objektes auf dieser Erde ist mittels GeoLocation spezifiziert.
GeoLOD ermöglicht es unterschiedlich detaillierte Ebenen von Objekten einzuset-
zen. Der Grad der Genauigkeit hängt davon ab, wie nahe der Betrachter sich befin-
det. Somit ist es möglich Texturen für die Erde mit unterschiedlich hoher Auflösung
zu verwenden. Je weiter sich der Benutzer einzoomt, umso detailliertere Texturen
werden eingesetzt. Die Beschreibung von Geospatial -Knoten wird von GeoMeta-
data unterstützt. Mittels GeoOrigin kann von geografischen Koordinaten in das
lokale kartesische Koordinatensystem konvertiert werden. GeoPositionInterpolator
ermöglicht eine Interpolation von geografischen Koordinaten. Der GeoProximity-
29
2 Hintergrund
Sensor generiert Events, sobald der Betrachter einen Bereich betritt bzw. verlässt
oder sich in diesem bewegt. GeoTouchSensor bietet dieselben Funktionalitäten wie
TouchSensor. Zusätzlich werden jedoch auch die Koordinaten retourniert. Durch
GeoViewpoint ist es möglich Viewpoints durch Längen- und Breitengrade zu defi-
nieren.
2.2 Extended Stylesheet Language Transformation -
XSLT
XSLT bezeichnet eine Sprache, mit der ein XML-Dokument in ein anderes XML-
Dokument umgewandelt werden kann. XSLT ist ein Teilbereich von XSL (Exten-
sible Stylesheet Language), einer Stylesheet Sprache für XML. In der XML-Datei
wird der Inhalt definiert, für die Darstellung ist ein XSL-Dokument erforderlich.
In der XSL-Datei sind Regeln für die Transformation festgelegt. [43] [44]
Quelltext 2.12 zeigt ein XML-Dokument, das mittels XSL (siehe Quelltext 2.13)
in eine X3D-Datei (siehe Quelltext 2.14) transformiert wird.
<?xml ve r s i on=” 1 .0 ” encoding=” i so −8859−1”?>
<?xml−s t y l e s h e e t type=” text / x s l ” h r e f=” trans form . x s l ”?>
<kugel>
<verschiebung >4 0 0</verschiebung>
<radius >2.0</ radius>
<farbe >0 0 1</farbe>
<beschre ibung>Kugel</beschre ibung>
</kugel>
Quelltext 2.12: Beispiel eines XML-Dokuments.
30
2 Hintergrund
<?xml ve r s i on=” 1 .0 ” encoding=”UTF−8”?>
<x s l : s t y l e s h e e t v e r s i on=” 1 .0 ” xmlns : x s l=”http ://www.w3 . org
/1999/XSL/Transform”>
<x s l : output method=”xml” ve r s i on=” 1 .0 ”
encoding=”UTF−8” . . . / >
<x s l : template match=”/”>
<X3D p r o f i l e=” Immersive” ve r s i on=” 3 .0 ” . . . >
<head>
<meta content=”Autor” name=”Angel ika P r e i s s l e r ”/>
</head>
<Scene>
<x s l : apply−templates/>
</Scene>
</X3D>
</x s l : template>
<x s l : template match=” kuge l ”>
<Transform>
<x s l : a t t r i b u t e name=”DEF”>
<x s l : value−o f s e l e c t=” beschre ibung ”/>
</x s l : a t t r i bu t e >
<x s l : a t t r i b u t e name=” t r a n s l a t i o n ”>
<x s l : value−o f s e l e c t=” versch iebung ”/>
</x s l : a t t r i bu t e >
<Shape>
<Sphere>
<x s l : a t t r i b u t e name=” rad iu s ”>
<x s l : value−o f s e l e c t=” rad iu s ”/>
</x s l : a t t r i bu t e >
</Sphere>
31
2 Hintergrund
<Appearance>
<Mater ia l>
<x s l : a t t r i b u t e name=” d i f f u s eCo l o r ”>
<x s l : value−o f s e l e c t=” fa rbe ”/>
</x s l : a t t r i bu t e >
</Mater ia l>
</Appearance>
</Shape>
</Transform>
</x s l : template>
</x s l : s t y l e s h e e t >
Quelltext 2.13: Beispiel eines XSL-Dokuments.
Für diese Transformation ist ein XSLT -Prozessor (z.B. Xalan-Java, SAXON,
XT, Oracle XDK ) notwendig. [37] Nähere Details zur Verwendung der XSL-
Transformation, in Zusammenhang mit der Applikation, folgen in Kapitel 4.
32
2 Hintergrund
<?xml ve r s i on=” 1 .0 ” encoding=”UTF−8”?>
<!DOCTYPE X3D PUBLIC ”http ://www. web3d . org / s p e c i f i c a t i o n s /
x3d−3.1. dtd”
” f i l e : ///www. web3d . org /TaskGroups/x3d/ t r a n s l a t i o n /
x3d−3.1. dtd”>
<X3D p r o f i l e=” Immersive” ve r s i on=” 3 .0 ”
xmlns : xsd=”http ://www.w3 . org /2001/XMLSchema−i n s t anc e ”
xsd : noNamespaceSchemaLocation=”http ://www. web3d . org /
s p e c i f i c a t i o n s /x3d−3.1. xsd”>
<head>
<meta content=”Autor” name=”Angel ika P r e i s s l e r ”/>
</head>
<Scene>
<Transform DEF=”Kugel” t r a n s l a t i o n=”4 0 0”>
<Shape>
<Sphere rad iu s=” 2 .0 ”/>
<Appearance>
<Mater ia l d i f f u s eCo l o r=”0 0 1”/>
</Appearance>
</Shape>
</Transform>
</Scene>
</X3D>
Quelltext 2.14: Transformiertes X3D-Dokument.
2.3 Wikis
Ein Wiki ist eine Sammlung von Webseiten (Artikel), die von Benutzern erstellt,
bzw. bearbeitet werden und die untereinander verlinkt sind. Aus einer Vielzahl
von Artikeln entsteht ein umfangreiches Nachschlagewerk. [19] Der Unterschied
zwischen einer herkömmlichen Webseite und einem Wiki liegt in den Möglichkei-
ten, neue Seiten zu erstellen und existierende Seiten zu bearbeiten. Wikis verwirk-
33
2 Hintergrund
Web 1.0 Web 2.0
DoubleClick Google AdSense
Ofoto Flickr
Akamai BitTorrent
mp3.com Napster
Britannica Online Wikipedia
personal websites blogging
evite upcoming.org and EVDB
domain name speculation search engine optimization
page views cost per click
screen scraping web services
publishing participation
content management systems wikis
directories (taxonomy) tagging (
”
folksonomy“)
stickiness syndication
Tabelle 2.3: Web 2.0 anhand von Beispielen. [38]
lichen den Grundgedanken vom Informationsaustausch im World Wide Web und
ermöglichen somit ein kollaboratives Arbeiten. [21] [10] Die Basis des historischen
3D-Atlasses bildet ein Wiki (MediaWiki). Durch eine Vielzahl von Benutzern ist
es möglich, eine große Datenmenge von historischen Inhalten mit geografischen
Daten zu erhalten. Das Wiki-Projekt Wikipedia ist das beste Beispiel dafür.
Web 2.0
Wikis bilden einen wichtigen Bestandteil von Web 2.0. Tim O’Reilly beschreibt
in seinem Bericht [38] den Begriff von Web 2.0 als eine Art Zusammenfassung der
neuesten Tendenzen im Web-Bereich. In Tabelle 2.3 wird der Begriff anhand von
Vergleichen illustriert. Web 2.0 ist keine neue Technologie, sondern lässt sich als
eine Menge von Prinzipien und Methoden beschreiben, siehe Abbildung 2.12. Web
als eine Plattform wurde als eine dieser Prinzipien definiert. Es dreht sich alles um
die Interaktivität im World Wide Web. [38][3]
Gemeinsame Informationen(Harnessing Collective Intelligence) nutzbar zu ma-
chen, ist das Erfolgskonzept einiger großen Firmen wie Google, Yahoo!, eBay oder
Amazon. Die gemeinsame Nutzung von Informationen beschreibt zugleich auch
34
2 Hintergrund
Abbildung 2.12: Tim O’Reilly’s Gedanken zu Web 2.0. [38]
das zentrale Prinzip von Web 2.0. [38] Der Inhalt wird von Benutzern erstellt,
nicht von Experten. Amazon publiziert zum Beispiel Rezensionen von Kunden in
ihrem Onlineshop. Die Idee ist es, nicht selbst Inhalte zu erstellen, sondern die Bei-
träge der Benutzer zu verwenden, diese zu strukturieren und Vorteile daraus zu
ziehen bzw. dadurch die Qualität zu steigern. Auch Wikis folgen diesem Prinzip.
Jeder Benutzer kann einen Eintrag in einem Wiki erstellen bzw. diesen editieren
oder auch andere Artikel bearbeiten. Wikipedia gehört zu einer der erfolgreichsten
Webseiten in den letzten Jahren. [19]
Ein weiterer wichtiger Aspekt von Web 2.0 sind Dienstschnittstellen, welche die
Integration von Inhalten anderer Webseiten in die eigene ermöglichen. Beispiele
dazu wären, Fotos von Flickr oder News von Zeitungen in die eigene Webseite
einzubinden. [3]
35
2 Hintergrund
2.3.1 Wiki-Konzept
Das erste Wiki wurde von Ward Cunningham 1995 entwickelt und wurde als Wiki-
WikiWeb bezeichnet. Die ursprüngliche Idee war es, ein neues Dokumentationssys-
tem für Software-Entwicklung zu schaffen. Die Bezeichnung
”
WikiWiki“ ist hawai-
ianisch und bedeutet übersetzt
”
schnell“ oder
”
sich beeilen“ und bezieht sich auf
die Schnelligkeit, in der Informationen über ein Wiki bereitgestellt werden können.
[10] Aus diesem WikiWikiWeb haben sich weitere Wiki-Engines entwickelt, z.B.
MediaWiki, UseModWiki, PmWiki, FlexWiki, TWiki, JSPWiki. [21]
Das Konzept eines Wikis besticht durch die Einfachheit in der neue Seiten er-
stellt bzw. vorhandene Seiten bearbeitet werden können. Über jedem Eintrag steht
ein Verweis auf
”
Seite bearbeiten“, der es ermöglicht jeden vorhandenen Artikel
zu bearbeiten und sofort online zu stellen. Neue Seiten können durch das Set-
zen eines neuen Links generiert werden. Existiert die Seite, auf die verlinkt wird,
noch nicht, kann ein neuer Eintrag erstellt werden. Über die Auflistung der Ver-
sionen und Autoren können Veränderungen nachvollzogen, verglichen und auch
rückgängig gemacht werden. [10][21]
2.3.2 Anwendungsgebiete
Die Hauptanwendungsmöglichkeit von Wikis liegt in der Nutzung als Wissens-
datenbank. Wikipedia, die erfolgreichste Wiki-Seite, stammt aus diesem Anwen-
dungsgebiet. Bei Wikipedia werden Informationen zu jedem erdenklichen Thema
gesammelt. Der Aufbau eines Wikis entspricht dem eines Lexikons. Über Stichwor-
te wird auf den Inhalt zugegriffen, durch Links werden Verweise auf andere Begriffe
gesetzt. Die Gestaltung und das Layout rücken in den Hintergrund, die Erstellung
der Information wird somit erleichtert und einheitlich gehalten. [21] Wikis dienen
immer öfter der Erstellung von Dokumentationen und kommen auch vermehrt in
Schulen zum Einsatz. [10]
Private Webseiten werden sehr oft durch ein Wiki ersetzt, aufgrund ihrer einfa-
chen Syntax und Wartungsmöglichkeiten. [21]
Weitere Anwendungsgebiete für Wikis sind als Groupware in Unternehmen, als
Plattform für Diskussionen oder als öffentlich zugängliches Notizbuch. [10][21]
36
2 Hintergrund
2.3.3 Funktionalitäten
Generell gibt es bei Wikis keinen Standard für das eingesetzte Textformat, es wird
jedoch an einem Standard namens WikiCreole gearbeitet. Fast alle vorhandenen
Wikis leiten ihre Syntax vom ersten Wiki (WikiWikiWeb) ab, somit besteht eine
Ähnlichkeit bei den wichtigsten Funktionalitäten. Ist die Formatierung mit der
Wiki-Syntax nicht ausreichend, ist es auch möglich, zusätzlich HTML-Elemente
oder Cascading Style Sheets (CSS) [42] zu verwenden. [21] Nachfolgend werden
die wichtigsten Funktionalitäten eines Wikis beschrieben.
Bearbeitung der Seiten
Das Grundprinzip eines Wikis ist, dass jeder Artikel für jeden Benutzer verfügbar
ist. Somit kann jeder Benutzer neue Artikel erstellen und beliebige Artikel von
anderen Autoren bearbeiten. Aufgrund dieses Prinzips entsteht eine ständige Ver-
besserung und Erweiterung der Artikel. Durch die Mitarbeit von vielen Benutzern
kann eine umfangreiche Datensammlung erstellt werden. Über die Versionskon-
trolle ist es möglich, Änderungen zu verfolgen und damit die Qualität der Artikel
durch Selbstkontrolle der Benutzer sicher zu stellen. Falsche Informationen und
willkürliche Veränderungen können von Benutzern selbst rückgesetzt werden.
Verlinkung der Seiten
Durch Links (Hyperlinks) können verschiedene Seiten (Hypertext) miteinander
verbunden werden. Durch das Setzen von Links wird die Navigation durch die
einzelnen Artikel erleichtert, da miteinander verlinkte Seiten zu ähnlichen Themen
gehören. Somit kann ein großer Themenbereich nicht nur auf einer, sondern auf
mehreren Seiten abgedeckt werden. Verweist ein Link auf eine Seite, die noch nicht
vorhanden ist, wird dieser Link anders dargestellt, als bei existierenden Seiten.
Besteht also noch kein Artikel, so kann der Benutzer diesen erstellen. [10][21]
Es wird zwischen drei Verlinkungen in einem Wiki unterschieden: Wiki-interne
Links, InterWiki: Links zu anderen Wikis und externen Links ins Web. [10][21]
Wiki-interne Links verweisen auf Seiten innerhalb eines Wikis. In den Anfängen
des Wikis wurden diese durch gemischte Groß-/Kleinschreibung gesetzt, die
37
2 Hintergrund
Schreibweise wurde als WikiWords oder CamelCase bezeichnet, zum Bei-
spiel
”
NeuerLink“. Diese Variante wird jedoch nicht mehr von allen Wikis
unterstützt. Als Alternative zu den WikiWords gibt es so genannte Free-
Links, die von allen Wikis akzeptiert werden. Das Wort, das verlinkt wird,
wird in doppelten eckigen Klammern geschrieben.
[[Seitentitel]]
Es besteht auch die Möglichkeit, anstatt des Titels der Seite eine alternative
Beschreibung als Linkverweis anzugeben.
[[Seitentitel|Beschreibung]]
InterWiki ist die Bezeichnung für die Verlinkung in andere Wikis. Die Grundi-
dee ist, verschiedenste Wikis einfach miteinander zu vernetzen. Dazu ist es
notwendig, externe Wikis in einer Konfigurationsdatei mit Bezeichnung und
URL zu definieren, zum Beispiel:
WikiPediaDE http://de.wikipedia.org/wiki/
Danach wird die gewünschte Seite mit folgender Syntax aufgerufen:
[[WikiPediaDE:Seitentitel]]
Der Seitentitel wird von der Wiki-Engine direkt an jene URL angehängt, die
in der Konfigurationsdatei angegebenen wurde.
Externe Links verweisen auf beliebige externe Inhalte, dabei kann es sich auch um
andere Wikis handeln. Der Link zu einer Webseite wird in einfachen eckigen
Klammern geschrieben.
[http://www.tuwien.ac.at]
38
2 Hintergrund
2.4 Grundlagen zu geografischen Daten
In den folgenden Kapiteln werden grundlegende Begriffe zur Verarbeitung und
Standardisierung von geografischen Daten erläutert. Abschließend werden verschie-
dene Geo-Browser näher betrachtet.
2.4.1 Grundbegriffe
Geo-Objekte
Geometrische Informationen sind in einem Punkt verankert, dieser ist die Grundla-
ge aller weiteren räumlichen Objekte (Geo-Objekte) wie Linie, Fläche und Körper.
[2] Geo-Objekte sind definiert durch ihre Geometrie, Topologie, Thematik und
Dynamik.
Die Geometrie beinhaltet sämtliche Informationen zur Lage und Größe eines
Geo-Objektes. Diese Angaben erfolgen auf der Grundlage eines eindeutigen räumli-
chen Bezugssystems. Es können verschiedene Bezugssysteme herangezogen werden,
wie zum Beispiel kartesisches Koordinatensystem, GPS-Koordinaten. Geo-Objekte
selbst werden als Vektor- oder Rastermodell dargestellt. Das Vektormodell besteht
aus gerichteten Vektoren, diese sind durch einen Start- und Endpunkt (Koordina-
ten) eindeutig definiert. Neben den Koordinaten müssen auch Informationen ge-
speichert werden, die die Zugehörigkeit von Punkten (Vektoren) zu Linien und von
Linien zu Flächen beschreiben. Beim Rastermodell wird eine Fläche (zumeist ein
Quadrat - Pixel) als Grundelement herangezogen. Durch die Angabe eines Spalten-
und Zeilenindexes wird jeder Pixel eindeutig definiert. So wird ein Punkt durch
einen Pixel, eine Linie und eine Fläche durch mehrere aneinander gereihte Pixel
dargestellt. [8]
Die Topologie beschreibt die relative Lage und die räumlichen Beziehungen zu
anderen Geo-Objekten. Die relative Lage von Objekten ändert sich nicht. Die
Geometrie der Geo-Objekte wird abstrahiert, wenn die Topologie betrachtet wird.
Nachbarschaften, Teilmengen und Überschneidungen bilden zentrale Konzepte der
Topologie. Die sechs möglichen topologischen Beziehungen der Grundformen Punkt,
Linie und Fläche im zweidimensionalen Bereich zeigt Abbildung 2.13.
Weitere Eigenschaften von Geo-Objekten sind die Thematik und die Verände-
39
2 Hintergrund
Abbildung 2.13: Topologische Beziehungsarten der Grundformen Punkt, Linie und
Fläche. [8]
rung (Dynamik), wobei zwischen zeitlichen und räumlichen Veränderungen unter-
schieden wird. [8]
Koordinatensysteme
Die Darstellung der Geo-Objekte, entweder im Vektor- oder Rastermodell defi-
niert, erfolgt in einem kartesischen Koordinatensystem. Neben diesem System sind
Polarkoordinaten von großer Bedeutung. Ein Vergleich zwischen den beiden Sys-
temen wird in der Abbildung 2.14 gezeigt.
Die Umrechnung zwischen den zwei Koordinatensystemen im dreidimensionalen
Fall erfolgt durch folgende Formeln: [8]
Polarkoordinaten in kartesische Koordinaten:
P (r, α, β) : x = r sinβ cosα
y = r sinβ sinα
z = r cosβ
In einigen Bereichen wird auch diese Umrechnung verwendet:
P (r, α, β) : x = r cosβ cosα
y = r cosβ sinα
z = r sinβ
40
2 Hintergrund
Abbildung 2.14: Darstellung eines Punktes in Polarkoordinaten und in kartesi-
schen Koordinaten, jedes in 2D und 3D. [8]
Kartesische Koordinaten in Polarkoordinaten:
P (x, y, z) : r =
√
(x2 + y2 + z2)
α = arctan y/x (für x 6= 0)
β = arctan
√
(x2 + y2/z
für x = 0 und y = r ist α = Π/2
für x = 0 und y = −r ist α = −Π/2
Jeder Punkt wird eindeutig auf einer Kugel definiert, wenn der Radius r konstant
ist. Im Falle der Erde wird dieser Radius auf 6.371 km gesetzt. Die Koordinaten
eines Punktes ergeben sich aus den Winkeln ϕ (Geografische Breite) und λ (Geo-
grafische Länge). Das Geografische Koordinatensystem besteht aus diesen beiden
Winkeln, siehe Abbildung 2.15. [8]
- Das Geografische Gradnetz besteht aus Breiten- und Längenkreisen.
- Der Kreis, dessen Ebene durch den Erdmittelpunkt geht und senkrecht zur
Rotationsachse der Erde steht, ist der Äquator.
- Als Breitenkreise oder Parallelkreise werden die Kreise bezeichnet, die par-
allel zum Äquator verlaufen. Der Winkel zwischen einem Punkt auf der
41
2 Hintergrund
Abbildung 2.15: Zeigt das geografische Koordinatensystem. [8]
Oberfläche der Kugel und der Äquatorebene, entlang des entsprechenden
Längenkreises, wird als Geografische Breite bezeichnet, 0◦ = Äquator, -90◦
= Südpol, 90◦ = Nordpol.
- Kreise, die durch beide Pole und vertikal zum Äquator verlaufen, werden
als Längenkreise oder Meridiane bezeichnet. Die Sternwarte von Greenwich
wurde als Nullmeridian definiert, von diesem ausgehend wird je 180◦ nach
Osten und Westen gerechnet.
- Der Äquator und alle Meridiane werden als Großkreise bezeichnet, weil sie
denselben Radius wie die Erde besitzen.
Ellipsoide
Bei exakten Koordinatenbestimmungen darf nicht davon ausgegangen werden, dass
die Erde der Form einer Kugel entspricht. Hier muss die Erde mit Ellipsoiden
angenähert werden. Unter anderem finden hier Ausbuchtungen am Äquator und
Abflachungen an den Polen Berücksichtigung. Diese Ellipsoide werden durch die
Hauptachse (längere Achse) und die Nebenachse (kürzere Achse) definiert und ent-
stehen durch die Drehung um die Nebenachse. Aufgrund weiterer Abweichungen
42
2 Hintergrund
Abbildung 2.16: Je nach Region werden unterschiedliche Referenzellipsoide ver-
wendet. [8]
werden in unterschiedlichen Gebieten verschiedene Ellipsoide eingesetzt. Abbil-
dung 2.16 zeigt die Verwendung von unterschiedlichen Ellipsoiden. [8]
2.4.2 Formate für Geodaten
Die Nachfrage nach Geodaten ist in den letzten Jahren stark gestiegen. Nicht nur
traditionelle Abnehmer, wie Umwelt- und Planungsämter sind an diesen Daten in-
teressiert, sondern auch Wirtschaftsunternehmen zur Organisation von Vertriebs-
gebieten, Location-based Services, Verkehrsnavigation oder zur Optimierung ihrer
Leitungssysteme. [8]
Aufgrund der Komplexität von geografischen Daten ist es notwendig diese zu
standardisieren, um eine sinnvolle Weiterverarbeitung im Internet zu gewährleis-
ten. Zu einem Geoinformationssystem (GIS ) gehören Anwendungen und entspre-
chende Daten. Ein GIS ist für die Erfassung, Analyse, Verwaltung und Präsentati-
on von Geodaten zuständig. Nachteile dieser Systeme sind die komplexe Installati-
on und Handhabung. Durch die gestiegene Nachfrage nach Geodaten mussten diese
Systeme überarbeitet und leichter bedienbar gemacht werden, zum Beispiel eine
Aufteilung in Funktionseinheiten. Das Open Geospatial Consortium (OGC) arbei-
tet an einer Integration von Geoinformationen in die IT-Technologie. Das OGC
besteht aus über 300 Firmen, Behörden und Universitäten. Weiters beschäftigt
sich auch ISO mit der Standardisierung von Geoinformationen und Geodaten. [16]
43
2 Hintergrund
GML
GML (Geography Markup Language) ist ein von OCG entwickelter Standard für
geografische Informationen. Dieser Standard ist ein offenes Format um geografische
Objekte und Anwendungen zu beschreiben, und dient gleichzeitig als Austausch-
format. GML (derzeit Version 3.1.1) basiert auf XML und ist für die Strukturie-
rung des geografischen Inhalts zuständig. Die Darstellung der Daten kann durch
unterschiedliche Art und Weise erfolgen, z. B. X3D, SVG.
Objekte werden durch Features beschrieben, wobei zwischen räumlichen und
nichträumlichen Features unterschieden wird. Räumliche Features beinhalten eine
geografische Position. Ein Feature wiederum besteht aus einer Liste von Geometri-
en und Eigenschaften. Eine Geometrie beschreibt die geometrischen Eigenschaften
eines Objekts unter Verwendung von geometrischen Formen (Punkt, Linie, Kur-
ven, Polygone). Eigenschaften werden durch Name, Typ und Wert definiert. Die
Spezifikation von GML ist in Profilen (wie X3D, siehe Kapitel 2.1.4) unterteilt,
z.B. Point Profile, GML Simple Feature Profile. Jedes Profil beinhaltet eine Teil-
menge von definierten Elementen. [56] [20] Quelltext 2.15 zeigt ein Beispiel in dem
ein Gebäude über die Koordinaten eines Punktes definiert ist. Durch die Angabe
von srsName wird auf ein Bezugssystem verwiesen. [20] [2] Die Spezifikation zu
GML kann unter [36] nachgelesen werden.
<Feature f i d=”1” f type=”gebaeude”>
<Property name=” stockwerke ” type=” i n t e g e r ” value=”3”/>
<gm l : l o c a t i on>
<gml:Point gml:srsName=”urn:EPSG:geographicCRS:
62836405”>
<gml:pos>−31.936 115.834</ gml:pos>
</ gml:Point>
</ gm l : l o c a t i on>
</Feature>
Quelltext 2.15: Beispiel eines GML-Dokuments.
44
2 Hintergrund
KML
KML (Keyhole Markup Language) wurde ursprünglich von der Firma Keyhole
entwickelt. KML ist ein offenes Format (basiert auf XML, teilweise auf GML) und
wird als Datenaustauschformat für GoogleEarth verwendet. In KML wird sowohl
der Inhalt als auch die Darstellung des Inhaltes definiert, ähnlich wie in HTML.
Ein KML-Dokument kann in zwei Varianten abgespeichert werden: .kml, .kmz. Die
Visualisierung einer kml-Datei erfolgt in Google Earth. KML bietet Möglichkeiten
Orte durch Icons oder Bezeichnungen zu bestimmen, Blickpunkte und Kamera-
positionen zu definieren, die Erdoberfläche mit Bildern zu überlagern, Stile zu
definieren, Elemente zu gruppieren, Animationen zu erzeugen und KML Dateien
dynamisch nachzuladen. [55] [15]
Quelltext 2.16 zeigt ein Beispiel einer KML Datei. Placemark bildet das zentrale
Element und wird für die Markierung einer geografischen Position verwendet. Es
können Geometrien (Punkt, Linie, Fläche), die dazugehörigen Koordinaten (coor-
dinates), Icons (IconStyle) und die Darstellung des Placemarks definiert werden.
Mittels LookAt kann ein Blickpunkt angegeben werden, durch longitude und lati-
tude wird dieser über seinen Längen- und Breitengrad definiert. Optional können
heading (Orientierung), range (Höhe des Blickpunktes) und tilt (Neigung des Blick-
winkels) angegeben werden. [55] [15]
45
2 Hintergrund
<?xml ve r s i on =”1.0” encoding=”UTF−8”?>
<kml xmlns=”http :// earth . goog l e . com/kml/2.1”>
<Placemark>
<name>Stonehenge , England</name>
<de s c r i p t i on >
Stonehenge was bu i l t around 2500BC
</de s c r i p t i on >
<LookAt>
<l ong i tude >−1.826752</ long i tude>
<l a t i t ude >51.179045</ l a t i t ude >
<range >1500</range>
< t i l t >0</ t i l t >
<heading>0</heading>
</LookAt>
<Style>
<I conSty le>
<Icon>
<hre f>b e i s p i e l . png</hre f>
</Icon>
</IconSty le>
</Style>
<Point>
<coord inate s >−1.826752 ,51.179045 ,0 </coord inate s>
</Point>
</Placemark>
</kml>
Quelltext 2.16: Beispiel eines KML-Dokuments.
2.4.3 Geo-Browser
Für die Darstellung von geografischen Daten gab es bereits genügend Anwendun-
gen für Spezialisten. Jedoch fehlte es am Zugang und an der Aufbereitung dieser
Geodaten für die breite Masse. Seit der Existenz von Geo-Browser interessiert sich
46
2 Hintergrund
auch die breite Öffentlichkeit für geografische Daten. Dabei wird eine dreidimen-
sionale Erde für die Visualisierung dieser Informationen herangezogen. [57]
Zwei derzeit sehr bekannte Geo-Browser, Google Earth und World Wind von
NASA, werden nachfolgend näher betrachtet.
Google Earth
Seit 1993 arbeitete die aus Deutschland stammende Firma Art+Com am ers-
ten Geo-Browser, Terravision. Der Öffentlichkeit wurde dieses Projekt 1994 auf
der ITU-Konferenz (International Telecommunications Union) in Kyoto vorge-
stellt. Nach einer Präsentation auf der Siggraph wurde 1995 eine Installation
im Demonstrationszentrum von SGI übernommen. Terravision wurde in die SGI-
Grafikbibliothek Performer integriert. Der damalige Direktor der Grafikbibliothe-
ken von SGI, T. Jones, gründete ein paar Jahre später die Firma Keyhole, die
die Applikation Earth Viewer entwickelte. Keyhole wurde 2004 von Google ge-
kauft und der Namen der Applikation in Google Earth geändert. [40][57] Die erste
Betaversion von Google Earth wurde im Juni 2005 veröffentlicht. [22]
Google Earth basiert auf einem Server, der das entsprechende Kartenmaterial
liefert und einem Client, der die Daten visualisiert. [22] Google Earth ist in vier
Varianten erhältlich: die kostenlose Google Earth Version, siehe Abbildung 2.17,
Google Earth Plus, Google Earth Pro und die Lösung für Unternehmen, Goo-
gle Earth Enterprise. [14] Das Kartenmaterial dafür wird von Google zugekauft
bzw. wurde von der früheren Firma Keyhole übernommen. Derzeit gibt es nur
für einen kleinen Bereich der Erde hochauflösendes Kartenmaterial. Mittlerweile
beauftragt Google selbst Überflüge um geeignetes Bildmaterial zu Verfügung zu
haben. [57] Google Earth bietet eine Zoommöglichkeit für eine detaillierte Darstel-
lung der Erdoberfläche, es werden dabei immer hochauflösendere Satelliten- bzw.
Luftbilder geladen. [22] Der Benutzer kann nach Orten und Plätzen suchen, indem
der Name oder die Koordinaten des Ortes eingegeben werden. Jedoch sind einige
durchaus bedeutende Sehenswürdigkeiten der Ortsdatenbank nicht bekannt, wie
zum Beispiel der Ayers Rock in Australien. Durch Placemarks ist es möglich einen
geografischen Punkt zu markieren und mit Information zu versehen, siehe dazu
KML (Kapitel 2.4.2). Weiters können auch dreidimensionale Objekte (Großstädte
47
2 Hintergrund
Abbildung 2.17: Google Earth.
in Amerika) oder Straßenkarten angezeigt werden. Auch die Suche nach Adressen
ist möglich. [57]
NASA World Wind
World Wind kann kostenlos heruntergeladen werden. Der Geo-Browser unterliegt
einer Open-Source-Lizenz. Das verwendete Bildmaterial stammt aus frei verfügba-
ren Datenquellen. Vor allem für die USA, Frankreich und Deutschland steht hoch-
auflösendes Kartenmaterial zu Verfügung. Wie bei Google Earth ist auch bei World
Wind ein stufenloses Zoomen möglich. Der große Unterschied zu Google Earth ist,
dass World Wind für wissenschaftliche Zwecke entwickelt wurde. Die Menüleiste
wird so klein wie möglich gehalten, um eine bestmögliche Ansicht des Bildmateri-
als zu gewähren, siehe Abbildung 2.18. [22][40][57] Es kann nach Orten durch den
Namen (nur auf Englisch) oder den Koordinaten gesucht werden, weiters können
bevorzugte Orte als Hotspots gespeichert werden. Auch bei World Wind ist die
Ortsdatenbank sehr umfangreich, es werden auch sehr kleine, abgelegene Orte ge-
funden. Von der Applikation werden jedoch keine Orte gefunden, die unbewohnt,
48
2 Hintergrund
Abbildung 2.18: NASA World Wind.
aber bekannt sind, zum Beispiel der Ayers Rock. Auf WMS-Dienste (Web Mapping
Service), ein offener Standard von OCG, kann direkt zugegriffen werden. Dadurch
ist der Abruf von Daten aus verschiedenen Quellen möglich. So liefert die NASA
Informationen zu Naturphänomenen und Animationen, in denen Vorgänge auf der
Erde gezeigt werden. Derzeit können keine dreidimensionalen Objekte dargestellt
werden. Da World Wind als Open-Source frei zur Verfügung steht, kommen jedoch
laufend Erneuerungen hinzu.
Durch definierte Formate ist es möglich Daten untereinander auszutauschen.
Google Earth und World Wind liefern sehr gute Benutzerschnittstellen, bieten
aber nur eingeschränkte Möglichkeiten zur Mitarbeit an der Datenbasis. Bei beiden
Geo-Browsern ist ein spezieller Client zum Zugriff auf die Daten notwendig. Der
im Rahmen dieser Arbeit erstellte Prototyp bietet durch ein Wiki die Möglichkeit
der Mitarbeit von vielen Benutzern. Zusätzlich ist die Benutzerschnittstelle über
einen beliebigen Webbrowser verfügbar.
49
3 Entwurf des technischen Systems
Das Ziel des praktischen Teils der Arbeit ist es, eine technische Umgebung zur
Erstellung eines historischen 3D-Weltatlasses zu implementieren. Als Grundgerüst
für dieses System fungiert ein Wiki. In diesem werden die historischen Geodaten
von Wiki-Benutzern erstellt und mittels X3D visualisiert. Die technischen Anforde-
rungen an das System, das Konzept und die Architektur werden in diesem Kapitel
detailliert dargestellt.
3.1 Anforderungen
Durch Benutzer-Eingaben in ein Wiki sollen geografische Daten mit textuellen An-
notationen auf einer 3D-Weltkugel dargestellt werden. Ziel ist es, viele Benutzer
zu erreichen und die Eingabe so einfach wie möglich zu gestalten. Die erstell-
ten Inhalte im Wiki müssen in eine entsprechende Struktur gebracht werden, um
diese effizient weiterverarbeiten zu können. Aus diesem Grund werden die Daten
in einer XML-Struktur zusammengefügt und mittels Stylesheet Transformation
ein X3D-Dokument generiert. Weitere Anforderungen bestehen darin, über einen
Zeitbalken die historische Entwicklung der Welt zu verfolgen und nach bestimmten
Zeitperioden zu filtern.
In Abbildung 3.1 wird der gesamte Prozess von der Eingabe bis zur Ausgabe
der Daten dargestellt. Nachfolgend eine detaillierte Auflistung der Anforderungen:
1. Ein Wiki dient als Datenbasis für die Bearbeitung und Verwendung durch
eine große Anzahl von Benutzern. Für die Beschreibung der historischen und
geografischen Daten gibt es eine definierte Eingabemöglichkeit.
2. Extrahieren der Eingabedaten (Längengrad, Breitengrad, Beschreibungen,
...) um eine strukturierte Darstellungsweise zu erhalten (XML-Dokument).
50
3 Entwurf des technischen Systems
Abbildung 3.1: Ablauf des Visualisierungsprozesses.
3. XSL-Transformation eines XML-Dokuments um ein X3D-Dokument zu ge-
nerieren.
4. Visualisierung des X3D-Dokuments im Browser durch die Integration eines
X3D-Plug-ins.
5. Integration eines Zeitbalkens, um die historischen Entwicklungen verfolgen
zu können, bzw. Eingabemöglichkeiten von Zeitperioden, um die Ausgabe
auf bestimmte Zeitspannen festlegen zu können.
3.2 Konzept
3.2.1 Wiki-Engine
Als Wiki-Engine wird MediaWiki verwendet, diese wird unter anderem auch für
die Online-Enzyklopädie Wikipedia eingesetzt. MediaWiki unterliegt der GNU Ge-
neral Public License (GPL) und ist in PHP implementiert. MediaWiki wird als
Serverbasierende Software über einen Webserver (z.B. Apache [41] oder IIS [33])
betrieben. Als Datenbank kann MySQL [34] oder PostgreSQL [39] verwendet wer-
den. [32] In Abbildung 3.2 wird die Architektur von MediaWiki dargestellt.
MediaWiki unterstützt JavaScript, XHTML, Editier- und Formatierungsmöglich-
keiten, Cascading Stylesheets (CSS), Bildergalerien, Darstellung von mathemati-
schen Formeln und Schutzmaßnahmen gegen Vandalismus und Spamming. Durch
51
3 Entwurf des technischen Systems
Abbildung 3.2: Architektur von MediaWiki. [54]
Extensions und Spezialseiten ist es möglich MediaWiki mit Funktionen zu erwei-
tern, ohne direkt im Software-Kern Veränderungen vornehmen zu müssen. [21]
3.2.2 Seitentypen
Für den historischen Weltatlas wurde eine Klassifizierung der Seiten in unterschied-
liche Seitentypen vorgenommen.
Geografische Seiten
Geografische Seiten beinhalten das XML-Element points, das im Wikitext in-
kludiert wird. Dadurch erkennt das System, dass Daten auf der 3D-Weltkugel
darzustellen sind. Dieser Seitentyp wird in zwei Arten unterschieden:
1. Geo-Definitionsseite
Anhand von points-Elementen werden Geo-Objekte definiert; dabei beste-
hen folgende Möglichkeiten:
- Punkte: z.B. Städte, Orte
52
3 Entwurf des technischen Systems
- Linien: z.B. Landesgrenzen
- Flächen: z.B. Länder, Teile eines Landes
<points>Geo-Objekt</points>
Ein wichtiges Attribut dieser Geo-Objekte ist time, womit die zeitliche Kom-
ponente einer geografischen Information definiert werden kann.
2. Geo-Containerseite
Werden zwischen points keine geografischen Objekte definiert, dient dieses
XML-Element als Container. Dabei werden die Informationen aus den ver-
linkten Seiten geholt, die sich im Artikel befinden. Die geografische Visuali-
sierung wird dann aus den verlinkten Begriffen (Link 1, Link 2) generiert,
sofern diese Seiten Geo-Definitionsseiten sind.
<points></points>
Link 1
Link 2
Nicht geografische Seiten
Diese Seiten beinhalten kein XML-Element points. Sie entsprechen einer üblichen
Wiki-Seite. Diese Artikel dienen zur Beschreibung von Inhalten und zum Anzeigen
von zweidimensionalen Grafiken. Es wird dabei keine X3D-Darstellung generiert.
3.2.3 Linktypen
Abbildung 3.3 zeigt ein Beispiel, welche mögliche Verlinkungen von einem Artikel
ausgehen können und wie diese verarbeitet werden. Artikel (Seiten) werden als
Knoten und Verlinkungen als Kanten dargestellt. Der aktuell dargestellte Artikel
ist der Wurzel-Knoten. Alle Seiten, durch die die verstärkte durchgezogene Linie
führt, werden auf der dreidimensionalen Weltkugel visualisiert.
Bei jedem verlinkten Artikel wird geprüft, ob es sich um eine geografische Sei-
te handelt. Nur solche werden weiter verarbeitet und dargestellt. Bei einer nicht
53
3 Entwurf des technischen Systems
Abbildung 3.3: Skizzierung eines Verlinkungsbaums unter Verwendung von unter-
schiedlichen Seitentypen. Alle Artikel, die sich auf der verstärkten
durchgezogenen Linie befinden, werden am Weltatlas dargestellt.
geografischen Seite wird der gesamte Pfad verworfen, wie Abbildung 3.3 bei den
Pfaden Artikel.1.1 und Artikel.1.2 zeigt.
Handelt es sich um eine Geo-Definitionsseite, werden die Informationen aus dem
points-Element in X3D dargestellt, weitere verlinkte Artikel werden nicht verfolgt,
zum Beispiel die Pfade Artikel.2.1, Artikel.2.2 und Artikel.2.3.
Bei einer Geo-Containerseite wiederum werden alle verlinkten Seiten so lange
durchlaufen, bis eine Geo-Definitionsseite (Pfad Artikel.3.2.2.1 ) oder eine nicht
geografische Seite (Pfad Artikel.3.2.1 ) gefunden wird. Durch die Betrachtung von
Pfaden innerhalb der Baumstruktur wird die wiederholte Verwendung derselben
geografischen Information verhindert.
3.2.4 Integration von zeitlichen Verläufen
Historische Darstellungen werden aufbauend auf den in Kapitel 3.2.2 und 3.2.3 be-
schriebenen Konzepten erstellt. Dazu wird eine neue Geo-Containerseite erstellt,
die auf bereits vorhandene Geo-Definitionsseiten oder Geo-Containerseiten ver-
linkt, siehe Quelltext 3.1.
54
3 Entwurf des technischen Systems
Durch die Definition eines Zeitbereiches anhand der Attribute from und until
ist es möglich, sich nur jene Artikel anzeigen zu lassen, die sich innerhalb dieser
Zeitperiode befinden. Dabei wird das Attribut time der Geo-Objekte als Filter
herangezogen und nur jene Objekte angezeigt, bei denen die Jahreszahl, die in dem
Attribut definiert ist, sich zwischen from und until befindet. Die Visualisierung
der geografischen Informationen erfolgt anhand der Verarbeitung der vorhandenen
Links, wie in Kapitel 3.2.3 detailliert beschrieben. Durch Interaktionselemente ist
es möglich, sich den historischen Verlauf der Seiten anzusehen und zu navigieren.
Further in fo rmat ion . . .
<po in t s from=”1911” un t i l=”2007”></ po in t s>
[ [ Austr ia ] ]
[ [ Austr ia−Hungary 1911 ] ]
[ [ Austr ia 1 9 3 5 ] ]
[ [ Austr ia 1 8 8 5 ] ]
Quelltext 3.1: Zeitlicher Verlauf.
3.3 Architektur
Dieses Kapitel beschreibt die Integration der Applikation innerhalb von MediaWi-
ki. Die Verteilung der einzelnen Bereiche des Systems ist in Abbildung 3.4 skizziert.
Dabei ist ersichtlich, dass Erweiterungen sowohl auf Client- als auch auf Server-
seite erfolgt sind. Für die Umsetzung werden die von MediaWiki vorgesehenen
Möglichkeiten verwendet, wie Extension und Spezialseite.
3.3.1 Wiki-Extension
Für die Einbettung des X3D-Plug-ins in die HTML-Ausgabe an der Position des
points-Elements ist die Extension Point verantwortlich. Die Extension registriert
eine Callback-Funktion im Wiki, wodurch beim Auftreten des XML-Elements
points im Wikitext diese Funktion aufgerufen wird. [31] Wenn das Element nicht
55
3 Entwurf des technischen Systems
Abbildung 3.4: Architektur des technischen Systems mit Integration in MediaWi-
ki.
in der Wiki-Seite inkludiert ist, wird die Extension nicht ausgeführt und die X3D-
Anzeige für diesen Artikel nicht aktiviert. Dies ist bei nicht geografischen Seiten
der Fall.
3.3.2 Wiki-Spezialseite
Im MediaWiki können so genannte Spezialseiten erstellt werden. Diese bieten die
Möglichkeit, die Ausgabe vollständig zu definieren und dadurch verschiedene Me-
dientypen (MIME-Types) anzugeben. [30] Die Applikation definiert eine Spezi-
alseite, welche den X3D-Inhalt aus den Artikeln generiert. Dabei werden die in
Kapitel 3.2.2 und 3.2.3 beschriebenen Funktionalitäten verwendet, um geografi-
sche Daten und Links zu verarbeiten und daraus ein XML-Dokument zu erstellen.
Anschließend wird auf diesem XML-Dokument eine XSL-Transformation durch-
geführt, um damit eine X3D-Ausgabe zu generieren. Diese wird an den Browser
gesendet und mittels Plug-in angezeigt. Der detaillierte Ablauf wird in Abbil-
dung 3.5 dargestellt.
56
3 Entwurf des technischen Systems
Abbildung 3.5: Ablaufdiagramm für die Abarbeitung der Spezialseite.
57
3 Entwurf des technischen Systems
JavaScript
Mittels JavaScript werden sämtliche Interaktionen des Benutzers mit der X3D-
Szene verarbeitet. Dies ist der Fall bei der Benutzung der Interaktionselemente,
um durch einen zeitlichen Verlauf zu navigieren. Dabei wird eine Schnittstelle
(getNodeEventOut, setNodeEventIn) zum X3D-Plug-in für den Datenaustausch
verwendet.
X3D-Plug-in
Für die Darstellung einer X3D-Szene ist ein X3D-Plug-in notwendig. Dafür kann
jedes Plug-in verwendet werden, das die X3D-Spezifikation erfüllt. Nähere Details
zu vorhandenen Plug-ins sind in Kapitel 2.1.5 zu finden.
3.3.3 Benutzereingabe
Der Benutzer erstellt oder bearbeitet eine Wiki-Seite, zum Beispiel Wien. Zusätz-
lich zum textuellen Inhalt definiert der Autor die geografischen Informationen
durch das Hinzufügen des XML-Elements points. Quelltext 3.2 zeigt eine mögliche
Eingabe.
Desc r ip t i on o f the h i s t o r i c a l event . . .
<points>
<point de f=”Vienna” t rans=”0” desc=”Vienna 1 8 5 8 . . . ”
u r l=”http ://www. wien . gv . at /ma08/ ge s ch i ch t e / wh i s e i n l . htm”
time=”1858”>
<l a t >48.208616458792086</ la t>
<long >16.372697353363037</ long>
</point>
</points>
Other in fo rmat ion . . .
Quelltext 3.2: Beispiel einer Wikiseite mit geografischen und historischen Daten.
58
3 Entwurf des technischen Systems
Nachdem die Seite bearbeitet und gespeichert wurde, werden die Daten in der
Datenbank abgelegt. Bei den Eingabedaten handelt es sich um einen Wikitext.
3.3.4 Seite anzeigen
Abbildung 3.6 zeigt ein detailliertes Ablaufdiagramm für die Darstellung einer
Wiki-Seite, mit und ohne geografischem Inhalt. Beim Aufruf einer Wiki-Seite er-
folgt zuerst die Überprüfung, ob es sich um einen Artikel mit oder ohne Geodaten
handelt. Bei einem geografischen Inhalt wird das Plug-in aufgerufen, welches die
X3D-Szene anzeigt.
59
3 Entwurf des technischen Systems
Abbildung 3.6: Ablaufdiagramm für die Anzeige einer Wiki-Seite.
60
4 Implementierung des technischen
Systems
Diese Kapitel beschreibt die technische Umsetzung der bereits zuvor erwähnten
Konzepte.
4.1 Definition von Geo-Objekten
Mögliche Geo-Objekte sind Punkt, Linie und Fläche. Für jedes dieser Objekte
kann durch die Angabe von verschiedenen Parametern das Aussehen bestimmt
bzw. eine Beschriftung, Beschreibung und Verlinkung hinzugefügt werden.
In den folgenden Unterkapiteln wird die Syntax der einzelnen Elemente darge-
stellt.
4.1.1 Punkt
Ein Punkt wird durch das Element point definiert und durch folgende Attribute
beschrieben:
- def: Angabe des Titels
- trans: Transparenz (1 ... durchsichtig, 0 ... undurchsichtig - Dezimaler Wertebe-
reich zwischen 0 und 1)
- desc: Beschreibung des Elements
- url: Link zu einer internen oder externen Seite
- time: Definiert das Jahr des historischen Ereignisses (Integer)
61
4 Implementierung des technischen Systems
Das Element point enthält weitere Sub-Elemente wie lat und long. Wobei lat
die Angabe des Breitengrads (latitude) und long die Angabe des Längengrads
(longitude) beschreibt, siehe Quelltext 4.1.
<po in t s>
<point de f=”Salzburg ” t rans=” 0 .4 ” desc=”Salzburg . . . ”
u r l=”” time=”2000”>
< l a t>47.8001839</ l a t>
<long>13.0427455</ long>
</ po int>
</ po in t s>
Quelltext 4.1: Beispiel des Geo-Objekts: Punkt.
4.1.2 Linie
Eine Linie wird durch das Element line definiert. Wie bei point gibt es auch hier
mehrere Attribute:
- def: Angabe des Titels
- color: Farbe (in RGB-Schreibweise angeben, zum Beispiel 1 0 0 - für Rot)
- trans: Transparenz (1 ... durchsichtig, 0 ... undurchsichtig - Dezimaler Wertebe-
reich zwischen 0 und 1)
- desc: Beschreibung des Elements
- url: Link zu einer internen oder externen Seite
- time: Definiert das Jahr des historischen Ereignisses (Integer)
Eine Linie wird anhand mehrerer point-Elemente definiert. Dabei werden die
möglichen Attribute von point nicht verarbeitet. Die Koordinaten aus den Sub-
Elementen lat und long werden für die Darstellung einer Linie verwendet, siehe
Quelltext 4.2.
62
4 Implementierung des technischen Systems
<po in t s>
< l i n e de f=”Austr ia−Hungary” c o l o r=”1 0 0” t rans=” 0 .3 ”
desc=”Dual Monarchy Austr ia−Hungary 1911”
u r l=” ht tp : //en . w ik iped ia . org / wik i /Austr ia−Hungary”
time=”1911”>
<point>
< l a t>50 .15</ l a t>
<long>16 .7</ long>
</ po int>
<point>
< l a t>50 .45</ l a t>
<long>16 .25</ long>
</ po int>
. . .
</ l i n e>
</ po in t s>
Dual Monarchy Austr ia−Hungary in 1911 . . .
Quelltext 4.2: Beispiel des Geo-Objekts: Linie.
4.1.3 Fläche
Eine Fläche wird durch das Element area definiert, das dieselben Attribute besitzt
wie zuvor bei line beschrieben. Wie auch bei der Linie, wird eine Fläche durch
die Angabe mehrerer Punkte (point) dargestellt, siehe Quelltext 4.3.
63
4 Implementierung des technischen Systems
<po in t s>
<area de f=”Luxembourg” c o l o r=”0 0 1” t rans=” 0 .1 ”
desc=” borders o f benelux coun t r i e s (BEL, NL, LUX)”
u r l=” ht tp : //en . w ik iped ia . org / wik i /Benelux” time=”1990”>
<point>
< l a t>49.462</ l a t>
<long>6 .352</ long>
</ po int>
<point>
< l a t>49.567</ l a t>
<long>6 .361</ long>
</ po int>
. . .
</ area>
</ po in t s>
Quelltext 4.3: Beispiel des Geo-Objekts: Fläche.
4.2 Integration in MediaWiki-Umgebung
In diesem Kapitel werden technische Details zur Implementierung der Extension
und der Spezialseite beschrieben.
4.2.1 Wiki-Extension
Das Wiki ruft die Callback-Funktion renderPoints() bei Auftreten eines points-
Elements auf. Diese Funktion wird beim Laden der Extension (Point.php) über den
Event Handler registriert, siehe Quelltext 4.4. Dabei wird als erster Parameter der
Name des Elements (points) angegeben, siehe Codezeile 3.
64
4 Implementierung des technischen Systems
f unc t i on wfPoints ( ) {
g l oba l $wgParser ;
$wgParser−>setHook ( ” po in t s ” , ” renderPo int s ” ) ;
}
Quelltext 4.4: Registrierung der Callback-Funktion.
Die Funktion renderPoints() ist für die HTML-Ausgabe verantwortlich. Dieser
werden drei Argumente übergeben [31], siehe Quelltext 4.5:
$input: Der Inhalt, der zwischen <points> und </points> definiert wurde bzw.
NULL, wenn das Element geschlossen ist (<points/>).
$argv: Array der Attribute des Elements points: from und until.
$parser: Wikitext Parser, dieser verfügt über Informationen über den gesamten
Artikel. Der Parser wird verwendet um den Titel und den Wikitext zu er-
halten.
In renderPoints() wird überprüft, ob die Attribute from und until defi-
niert sind, siehe Codezeile 8 und 13. Trifft dies zu, werden zusätzlich zur X3D-
Ausgabe die Navigationselemente eingeblendet. Dafür wird eine weitere Funktion
(createEmbedded()) aufgerufen, siehe Codezeile 25. Neben den Attributen from,
until und dem Status ob ein Slider eingeblendet wird oder nicht, wird auch der
Name des Artikels mit übergeben.
65
4 Implementierung des technischen Systems
1 f unc t i on renderPo int s ( $input , $argv , $par se r ) {
2 // ge t t i t l e o f page
3 $ t i t l e = $parser−>mTitle−>getText ( ) ;
4
5 $showSl ider = true ;
6
7 // check i f from and u n t i l are se t , when not , show no
s l i d e r
8 i f ( ! i s set ( $argv [ ” from” ] ) && ! i s set ( $argv [ ” un t i l ” ] ) ) {
9 // show no s l i d e r
10 $showSl ider = fa l se ;
11 $un t i l = ”0” ;
12 $from = ”0” ;
13 } else i f ( ! i s set ( $argv [ ” un t i l ” ] ) ) {
14 // i f u n t i l i s not se t , s e t u n t i l to curren t year
15 $un t i l = date ( ”Y” ) ;
16 $from = $argv [ ” from” ] ;
17 } else {
18 $from = $argv [ ” from” ] ;
19 $un t i l = $argv [ ” un t i l ” ] ;
20 }
21
22 $ s i t e=’ / wik i / index . php/ Spe c i a l : GeoExtension/
23 ’ . $ t i t l e . ’ ’ ;
24 // embed X3D p lug in in t o w ik i a r t i c l e
25 $output=createEmbedded ( $from , $unt i l , $showSl ider ,
26 $ s i t e ) ;
27
28 r e turn $output ;
29 }
Quelltext 4.5: Funktion renderPoints().
66
4 Implementierung des technischen Systems
Die Funktion createEmbedded() ist für die Einbindung des X3D-Plug-ins ver-
antwortlich. Wobei als X3D-Dokument ein Verweis auf die Spezialseite mit dem
Namen des Artikels als Parameter übergeben wird, siehe Quelltext 4.6 (Codezeile
7 und 10 ).
1 f unc t i on createEmbedded ( $from , $unt i l , $showSl ider , $ s i t e )
2 {
3 $output = ’
4 <div>
5 . . .
6 <ob j e c t width=”720” he ight =”540” id=”X3DWorld”>
7 <param name=”s r c ” value=” ’ . $ s i t e . ’”/>
8 <param name=”type” value=”model/x3d+xml”/>
9 <param name=”a l i g n ” value=”cente r”/>
10 <embed s r c=” ’ . $ s i t e . ’ ” width=”720”
11 he ight =”540” TYPE=”model/x3d+xml”
12 name=”X3DWorld” s t y l e=”a l i g n : c en t e r ”/>
13 </object>
14 . . .
15 </div> ’ ;
16
17 r e turn $output ;
18 }
Quelltext 4.6: Integration des X3D-Plug-ins.
In Quelltext 4.7 wird die Integration der Navigationselemente (Slider und But-
tons) und die Ausgabe der Jahreszahlen dargestellt. Der Slider wird in Codzeile
10 bis 13 definiert, wobei für die Umsetzung die Yahoo! UI Library eingesetzt
wurde; für nähere Details siehe Kapitel 4.4.2. Als zusätzliche Möglichkeit für die
Navigation können auch Buttons verwendet werden, die in Codezeile 6-8, 15-18
und 22-27 definiert werden. Die aktuelle Jahreszahl (Codezeile 20 ) wird durch
JavaScript angepasst.
67
4 Implementierung des technischen Systems
1 f unc t i on createEmbedded ( $from , $unt i l , $showSl ider , $ s i t e )
2 {
3 . . .
4 i f ( $showSl ider ){
5 $output .= ’ . . .
6 <form>
7 <input type=”button” c l a s s=”btn” name=”prev ious ”
value=”<<” on c l i c k=”moveLeft ( ) ” . . . >
8 </form>
9 . . .
10 <div c l a s s=”yui−skin−sam”>
11 . . . // De f i n i t i o n des S l i d e r s
12 <s c r i p t type=”text / j a v a s c r i p t”> s l i d e r I n i t ( ’ . $from . ’
, ’ . $ un t i l . ’ ) ;</ s c r i p t >
13 </div>
14 . . .
15 <form>
16 <input type=”button” c l a s s=”btn” name=” l a t e r ”
17 value=”>>” on c l i c k=”moveRight ( ) ” . . . >
18 </form>
19 . . .
20 Year : <span id=”s l i d e r−value”> ’ . $from . ’</span>
21 . . .
22 <form>
23 <input type=”button” c l a s s=”btn” name=”a l l ”
24 value=”Show a l l ” on c l i c k=”showAllElements ( ) ” . . . >
25 <input type=”button” c l a s s=”btn” name=”animation ”
26 value=”Animation” on c l i c k=”startAnimat ion ( ) ” . . . >
27 </form> . . . ’ ;
28 } . . .
29 r e turn $output ;
30 }
Quelltext 4.7: Definition der Navigation mittels Slider und Buttons.
68
4 Implementierung des technischen Systems
4.2.2 Wiki-Spezialseite
Die Spezialseite (Geo extension body.php) ist für das Generieren der X3D-Ausgabe
zuständig, siehe Quelltext 4.8. Als Erstes wird durch den übergebenen Seitenna-
men der Inhalt des entsprechenden Artikels geholt (Codezeile 3 ). Da diese Spe-
zialseite nur für Geo-Definitions- oder Geo-Containerseiten aufgerufen wird, ist
ein points-Element vorhanden. Dieses Element wird durch Codezeile 5 extra-
hiert (parse points). Alle Links des übergebenen Artikels werden aus dem Wi-
kitext ausgelesen (Codezeile 7 ). Anschließend werden diese Links rekursiv abge-
arbeitet (Codezeile 8 ) und die jeweiligen Geo-Objekte verwendet. Dabei erfolgt
die Durchführung anhand des Algorithmus, wie in Kapitel 3.2.3 beschrieben. Die
Funktion collectLinks() retourniert die aneinander gefügten points-Elemente
aller verlinkten Artikel.
Die Geo-Objekte der Verlinkungen sowie des aktuellen Artikels werden kom-
biniert (Codezeile 10 ). Um eine vollständige XML-Struktur zu erhalten, werden
zusätzlich der XML-Header und das Wurzel-Element geoinformation hinzugefügt
(Codezeile 12-16 ).
Auf das erhaltene XML-Dokument wird eine XSL-Transformation angewendet
(Codezeile 18 ). Details zur Transformation werden im nachfolgenden Kapitel 4.3
behandelt. Die daraus resultierende X3D-Ausgabe wird an das Plug-in zurückge-
geben (Codezeile 20 ).
69
4 Implementierung des technischen Systems
1 f unc t i on execute ( $par ) {
2 . . .
3 $content = g e t c o n t e n t o f a r t i c l e (NS MAIN, $par ) ;
4
5 $output1 = pa r s e po i n t s ( $content , ”<po in t s ” , ”</points>” ) ;
6
7 $ l i n k l i s t = pa r s e va l u e s ( $content , ” [ [ ” , ” ] ] ” ) ;
8 $output = s e l f : : c o l l e c t L i n k s ( $ l i n k l i s t ) ;
9
10 $output = $output1 . $output ;
11 . . .
12 $xml doc = ”<?xml ve r s i on =\”1.0\”
13 encoding=\”ISO−8859−1\”?>
14 <?xml−s t y l e s h e e t type=\”text / x s l \”
15 hr e f=\”geo in format ion . x s l \”?>
16 <geo in format ion>” . $output . ”</geo in format ion>” ;
17
18 $x3d doc = xs l t r an s f o rma t i on ( $xml doc ) ;
19 . . .
20 echo $x3d doc ;
21 }
Quelltext 4.8: Spezialseite GeoExtension body.php.
4.3 XSL-Transformation
Nachdem die Eingabedaten in eine XML-Struktur gebracht wurden, wird aus dieser
mittels XSL-Transformation ein X3D-Dokument generiert. Nachfolgend wird die
Transformierung der Daten näher erläutert.
Bei der Transformation eines Punktes werden die eingegebenen Werte für Längen-
und Breitengrad in kartesische Koordinaten umgerechnet, siehe Quelltext 4.9. Die-
se dienen zur Darstellung des Punktes auf einer Kugel. Das Bogenmaß (rad) von
Längen- und Breitengrad muss noch jeweils berechnet werden, dies erfolgt durch
70
4 Implementierung des technischen Systems
folgende Formel: Winkel (in rad) = 2 π lat/360.
1 <x s l : t emp l a t e match=” po in t s / po int ”>
2 . . .
3 <Transform>
4 . . .
5 <x s l : a t t r i b u t e name=” t r a n s l a t i o n ”>
6 <x s l : v a l u e−o f s e l e c t=”$ rad iu s ∗math:cos (2∗$PI∗ l a t div
360)∗math:cos (2∗$PI∗ long div 360) ”/>
7 <x s l : t e x t> </ x s l : t e x t>
8 <x s l : v a l u e−o f s e l e c t=”$ rad iu s ∗math:s in (2∗$PI∗ l a t div
360) ”/>
9 <x s l : t e x t> </ x s l : t e x t>
10 <x s l : v a l u e−o f s e l e c t=”−($ rad iu s ∗math:cos (2∗$PI∗ l a t
div 360)∗math:s in (2∗$PI∗ long div 360) ) ”/>
11 </ x s l : a t t r i b u t e>
12 . . .
13 </Transform>
14 </ x s l : t emp l a t e>
Quelltext 4.9: Berechnung der kartesischen Koordinaten eines Punkts.
Des Weiteren werden die vom Benutzer definierten Attribute in die dafür zuständi-
gen X3D-Attribute geschrieben, siehe Quelltext 4.10.
Jedem X3D-Element eines Geo-Objekts wird eine ID vergeben, siehe Quell-
text 4.11 (Codezeile 8 und 18 ). Damit können Objekte explizit angesprochen wer-
den und so aus- und eingeblendet werden, wie zum Beispiel der Titel oder die
Geometrie eines Objekts.
71
4 Implementierung des technischen Systems
1 <x s l : t emp l a t e match=” po in t s / po int ”>
2 . . .
3 <Transform>
4 <x s l : a t t r i b u t e name=”DEF”>
5 <x s l : v a l u e−o f s e l e c t=”@def”/>
6 </ x s l : a t t r i b u t e>
7 </Transform>
8 . . .
9 </ x s l : t emp l a t e>
Quelltext 4.10: Transformation der eingegebenen Attribute.
1 <x s l : t emp l a t e match=” po in t s / po int ”>
2 <x s l : v a r i a b l e name=”cnt ”>
3 <xsl :number l e v e l=”any” count=” po in t s / po int ” />
4 </ x s l : v a r i a b l e>
5 . . .
6 <Shape>
7 <Appearance>
8 <Mater ia l d i f f u s eCo l o r=”1 0 0”>
9 <x s l : a t t r i b u t e name=”DEF”>
10 <x s l : v a l u e−o f s e l e c t=” concat ( ’ e 1 ’ , $ cnt ) ”/>
11 </ x s l : a t t r i b u t e>
12 . . .
13 </ Mater ia l>
14 </Appearance>
15 <Sphere rad iu s=” 0.0015 ”/>
16 </Shape>
17 . . .
18 </ x s l : t emp l a t e>
Quelltext 4.11: Vergabe von IDs.
72
4 Implementierung des technischen Systems
4.3.1 Punkt
Ist point ein direktes Sub-Element von points wird das Template points/point
verwendet, siehe Quelltext 4.12. Diese führt die Transformation eines Punktes
durch. Die Darstellung erfolgt anhand der Geometrie Sphere (Codezeile 16 ).
1 <x s l : t emp l a t e match=” po in t s / po int ”>
2 . . .
3 <Transform>
4 . . .
5 <Shape>
6 <Appearance>
7 <Mater ia l d i f f u s eCo l o r=”1 0 0”>
8 <x s l : a t t r i b u t e name=”DEF”>
9 <x s l : v a l u e−o f s e l e c t=” concat ( ’ e 1 ’ , $ cnt ) ”/>
10 </ x s l : a t t r i b u t e>
11 <x s l : a t t r i b u t e name=” transparency ”>
12 <x s l : v a l u e−o f s e l e c t=”@trans”/>
13 </ x s l : a t t r i b u t e>
14 </ Mater ia l>
15 </Appearance>
16 <Sphere rad iu s=” 0.0015 ”/>
17 </Shape>
18 . . .
19 <Bi l l boa rd axi sOfRotat ion=”0 0 0”>
20 . . .
21 </ B i l l boa rd>
22 . . .
23 </Transform>
24 </ x s l : t emp l a t e>
Quelltext 4.12: Transformation eines Punkts.
73
4 Implementierung des technischen Systems
4.3.2 Linie
Die Transformation von Linien erfolgt nach dem gleichen Prinzip wie zuvor bei den
Punkten. Anstatt des geometrischen Elements Sphere wird ein IndexedLineSet
verwendet, das sich aus einer Menge von Punkten zusammensetzt, siehe Quell-
text 4.13. In Codezeile 13-17 werden die Koordinaten der einzelnen Punkte defi-
niert. Die Indizes aus dem Attribut coordIndex Codezeile 7-12 werden verwendet,
um die einzelnen Punkte miteinander zu verknüpfen und damit eine Linie zu bil-
den.
74
4 Implementierung des technischen Systems
1 <x s l : t emp l a t e match=” po in t s / l i n e ”>
2 . . .
3 <Transform>
4 . . .
5 <Shape>
6 <IndexedLineSet co lorPerVertex=” f a l s e ”>
7 <x s l : a t t r i b u t e name=” coordIndex ”>
8 <x s l : f o r −each s e l e c t=” point ”>
9 <xsl :number l e v e l=” s i n g l e ” count=” point ”
format=”1 ” value=” po s i t i o n ( )−1” />
10 </ x s l : f o r −each>
11 <x s l : t e x t>−1</ x s l : t e x t>
12 </ x s l : a t t r i b u t e>
13 <Coordinate>
14 <x s l : a t t r i b u t e name=” point ”>
15 <xs l : app ly−templates />
16 </ x s l : a t t r i b u t e>
17 </Coordinate>
18 <Color> . . .</Color>
19 </ IndexedLineSet>
20 <Appearance>
21 . . .
22 </Appearance>
23 </Shape>
24 . . .
25 </Transform>
26 . . .
27 </ x s l : t emp l a t e>
Quelltext 4.13: Transformation einer Linie.
Für jeden Punkt der Linie werden die Koordinaten durch das Template
points/line/point berechnet, siehe Quelltext 4.14.
75
4 Implementierung des technischen Systems
<x s l : t emp l a t e match=” po in t s / l i n e / po int ”>
<x s l : v a l u e−o f s e l e c t=”$ rad iu s ∗math:cos (2∗$PI∗ l a t div
360)∗math:cos (2∗$PI∗ long div 360) ”/>
<x s l : t e x t> </ x s l : t e x t>
<x s l : v a l u e−o f s e l e c t=”$ rad iu s ∗math:s in (2∗$PI∗ l a t div
360) ”/>
<x s l : t e x t> </ x s l : t e x t>
<x s l : v a l u e−o f s e l e c t=”−($ rad iu s ∗math:cos (2∗$PI∗ l a t div
360)∗math:s in (2∗$PI∗ long div 360) ) ”/>
</ x s l : t emp l a t e>
Quelltext 4.14: Berechnung der einzelnen Punkte einer Linie.
4.3.3 Fläche
Eine Fläche besteht aus einer Menge von Punkten, die zu einer Fläche zusam-
mengefügt werden. Als Geometrie wird hier kein IndexedLineSet sondern ein
IndexedFaceSet verwendet. Ansonsten erfolgt die Verarbeitung wie bei der Linie.
4.3.4 Level of Detail
Bei der Transformation der Benutzereingaben wird unterschieden, ob ein Level
of Detail Element (nachfolgend als LOD-Element bezeichnet) angegeben wurde
oder nicht. Definiert der Benutzer kein LOD-Element, wird von der Spezialseite
ein nolod-Element in das XML-Dokument eingefügt. Dies ist notwendig, um im
Stylesheet die Textur der Erdoberfläche einzufügen, siehe Quelltext 4.15.
76
4 Implementierung des technischen Systems
<x s l : t emp l a t e match=” po in t s /nolod ”>
< x s l : i f t e s t=”count (// po in t s / lod ) = 0”>
<Group DEF=”Earth” con ta i n e rF i e l d=” ch i l d r en ”>
<x s l : c a l l −template name=” wor ld tex ”/>
</Group>
</ x s l : i f>
</ x s l : t emp l a t e
Quelltext 4.15: Verarbeitung bei nicht Definition des LOD-Elements.
Wird ein LOD-Element definiert, werden die kartesischen Koordinaten der vier
Eckpunkte der detaillierten Karte berechnet. Wie in Kapitel 2.1.6 beschrieben,
werden unterschiedlich detaillierte Geometrien eingeblendet. Die Unterscheidung
erfolgt durch das Attribut range, siehe Quelltext 4.16 (Codezeile 3 ). Dabei wird
außerhalb dieses Bereichs die gesamte Textur der Erde angezeigt (Codezeile 20-22 ).
Zoomt der Benutzer jedoch innerhalb dieses Bereichs, blendet das detailliertere
Kartenmaterial (Codezeile 5-17 ) und die gesamte Textur der Erdoberfläche ein
(Codezeile 18 ).
77
4 Implementierung des technischen Systems
1 <x s l : t emp l a t e match=” po in t s / lod ”>
2 <Group DEF=”Earth” con ta i n e rF i e l d=” ch i l d r en ”>
3 <LOD cente r=”0 0 0” range=” 1 .2 ”>
4 <Group>
5 <Shape >
6 <IndexedFaceSet s o l i d=” f a l s e ”>
7 . . .
8 </ IndexedFaceSet>
9 <Appearance>
10 <ImageTexture c on ta i n e rF i e l d=” tex ture ”
11 repeatS=” true ” repeatT=” true ”>
12 <x s l : a t t r i b u t e name=” u r l ”>
13 <x s l : v a l u e−o f s e l e c t=”@urlLOD”/>
14 </ x s l : a t t r i b u t e>
15 </ ImageTexture>
16 </Appearance>
17 </Shape>
18 <x s l : c a l l −template name=” wor ld tex ”/>
19 </Group>
20 <Group>
21 <x s l : c a l l −template name=” wor ld tex ”/>
22 </Group>
23 </LOD>
24 </Group>
25 </ x s l : t emp l a t e>
Quelltext 4.16: XSL-Transformation des LOD-Elements.
4.4 Navigation
Die Applikation bietet verschiedene Navigationsmöglichkeiten: Navigation inner-
halb des Plug-ins, Interaktionselemente (Slider, Buttons) oder durch eine erwei-
terte Suche nach Zeitperioden.
78
4 Implementierung des technischen Systems
4.4.1 X3D-Plug-in
Ein X3D-Plug-in bietet eine Vielzahl von Interaktionsmöglichkeiten mit der X3D-
Welt. Es besteht die Möglichkeit die Art der Bewegung zu definieren (gehen, glei-
ten, betrachten, fliegen, etc.) und die gewünschte Geschwindigkeit festzulegen.
Durch definierte Viewpoints kann die X3D-Szene aus verschiedenen Positionen
betrachtet werden. Innerhalb der XSL-Transformation werden diese Viewpoints
eingefügt, wie in Quelltext 4.17 dargestellt.
. . .
<Transform DEF=”Europe” r o t a t i on=”0 1 0 0 .3 ”>
<Transform ro t a t i on=”0 0 1 0 .9 ”>
<Viewpoint d e s c r i p t i o n=”Europe”
o r i e n t a t i o n=”0 1 0 1 .57 ” po s i t i o n=”2 0 0”/>
</Transform>
</Transform>
. . .
Quelltext 4.17: Definition von Viewpoints im XSL-Dokument.
4.4.2 Navigationselemente
Um die historische Entwicklung der Welt verfolgen zu können, muss den einzelnen
Geo-Objekten eine zeitliche Komponente hinzugefügt werden. Dies erfolgt durch
das Verwenden des Attributs time. In Quelltext 4.18 wird die Integration des
Zeitattributs dargestellt (Codezeile 3 ).
79
4 Implementierung des technischen Systems
1 <po in t s>
2 <point de f=”Graz” t rans=”0” desc=”Graz . . . ” u r l=””
3 time=”1988”>
4 < l a t> . . .</ l a t>
5 <long> . . .</ long>
6 </ po int>
7 </ po in t s>
Quelltext 4.18: Geo-Objekt mit dem Attribut time.
Durch die Angabe der Zeit ist es möglich die Geo-Objekte zeitlich zu sortie-
ren. Diese chronologische Sortierung dient als Basis für die Visualisierung des
zeitlichen Verlaufs. Durch die Definition der Attribute from und until bei Geo-
Containerseiten werden nur jene Geo-Objekte der verlinkten Seiten angezeigt, de-
ren time-Attribut innerhalb des Intervalls liegt, siehe Quelltext 4.19.
<po in t s from=”1950” un t i l=”2008”></ po in t s>
[ [ Graz ] ]
[ [ Innsbruck ] ]
Quelltext 4.19: Geo-Containerseite mit den Attributen from und until.
Werden die beiden Attribute from und until angegeben, fügt die Extension die
Navigationselemente (Slider und Buttons) ein. Für die Implementierung des Sliders
wurde die Yahoo! UI Library [58] eingesetzt, da HTML keine Slider-Funktionalität
anbietet. Beim Aufruf des Sliders werden die Werte der beiden Attribute from und
until übergeben, siehe Quelltext 4.20 (Codezeile 7 und 8 ).
80
4 Implementierung des technischen Systems
1 <div c l a s s=”yui−skin−sam”>
2 <div id=” s l i d e r−bg” tabindex=”−1” t i t l e=” S l i d e r ”>
3 <div id=” s l i d e r−thumb”>
4 <img s r c=”/ wik i / ex t en s i on s /GeoExtension/thumb−n . g i f ”>
5 </div>
6 </div>
7 <s c r i p t type=” text / j a v a s c r i p t ”> s l i d e r I n i t ( ’ . $from . ’ ,
8 ’ . $ un t i l . ’ ) ;</ s c r i p t >
9 </div>
Quelltext 4.20: Aufruf der Slider-Funktion.
Beim Initialisieren des Sliders werden diese für den Minimal- und Maximalwert
herangezogen, wie in Quelltext 4.21 dargestellt. Die Skalierung des Sliders erfolgt
je nach Zeitspanne. Das heißt, je größer diese Spanne ist, desto größer ist auch
die Schrittweite beim Navigieren. Bei jeder Zustandsänderung des Sliders wird die
Funktion changeEvent() aufgerufen (Codezeile 11 ).
1 f unc t i on s l i d e r I n i t (min , max) {
2 minYear = min ;
3 maxYear = max ;
4 var d i f f = max − min ;
5 var bgWidth = Dom. get ( bg ) ;
6 f a c t o r = 400/ d i f f ;
7
8 bgWidth . s t y l e . width=””+(Math . c e i l ( d i f f ∗ f a c t o r )+17)+”px” ;
9 s l i d e r = YAHOO. widget . S l i d e r . g e tHo r i z S l i d e r (bg , ” s l i d e r−
thumb” , 0 , Math . c e i l ( d i f f ∗ f a c t o r ) , Math . c e i l ( f a c t o r ) ) ;
10 u s eS l i d e r = true ;
11 s l i d e r . s ub s c r i b e ( ” change” , changeEvent ) ;
12 }
Quelltext 4.21: Funktion sliderInit().
81
4 Implementierung des technischen Systems
In dieser Funktion wird das neue Jahr berechnet und im Browser angezeigt,
siehe Quelltext 4.22 (Codezeile 8-9 ). Des Weiteren wird das Jahr der Funktion
showYear() als Parameter übergeben (Codezeile 7 ).
1 f unc t i on changeEvent ( o f f s e tFromStar t ) {
2 i f ( o f f s e tFromStar t > Math . c e i l ( d i f f ∗ f a c t o r ) )
3 s l i d e r . setValue (Math . c e i l ( d i f f ∗ f a c t o r ) ) ;
4
5 var year = Math . c e i l (minYear + ( o f f s e tFromStar t / f a c t o r ) ) ;
6
7 showYear ( year ) ;
8 var valnode = Dom. get ( va luearea ) ;
9 valnode . innerHTML = year ;
10 }
Quelltext 4.22: Funktion changeEvent().
Für die Änderung der X3D-Szene ist die Funktion showYear() zuständig, die
sich aufgrund der veränderten Slider-Position ergibt. Wird also der Slider verscho-
ben, werden die entsprechenden Geo-Objekte aus- bwz. eingeblendet. Durch die
erfolgte Vergabe von IDs bei der XSL-Transformation (siehe Kapitel 4.3) ist jedes
Objekt eindeutig ansprechbar.
Die JavaScript Funktionen getNodeEventOut(nodeName, eventOutName) und
setNodeEventIn(nodeName, eventInName, value) ermöglichen das Auslesen und
Verändern einzelner Elemente der X3D-Szene.
4.4.3 Suche nach Zeitperioden
Durch eine erweiterte Suche ist es möglich, sich nur jene historische Ereignisse
(Geo-Objekte) anzeigen zu lassen, die der eingegebenen Zeitperiode entsprechen.
Diese erweiterte Suchmöglichkeit wurde durch zwei Spezialseiten implementiert. In
der ersten (SearchTimePeriodExtension body.php) wird zunächst die Eingabemas-
ke definiert. Die Verarbeitung der Formulardaten wird von der zweiten Spezialseite
82
4 Implementierung des technischen Systems
(GeoSearchTimePeriodExtension body.php) übernommen. Diese ist von der Funk-
tionalität ähnlich der Spezialseite in Kapitel 4.2.2. Der Unterschied besteht darin,
dass bei dieser Seite sämtliche im Wiki vorhandene Artikel betrachtet werden und
nicht nur die verlinkten. Es werden jedoch nur jene Geo-Objekte angezeigt, die sich
innerhalb des Intervalls befinden, das der Benutzer über die Suchmaske definiert
hat.
83
5 Anwendungsbeschreibung
Dieses Kapitel beschreibt die Verwendung der Applikation aus Benutzersicht. Es
werden mögliche Anwendungen der Geo-Objekte innerhalb der verschiedenen Sei-
tentypen (Geo-Definitionsseite, Geo-Containerseite) dargestellt. Des Weiteren wer-
den unterschiedliche Navigationsmöglichkeiten gezeigt. Abschließend werden tech-
nische Voraussetzungen für die Inbetriebnahme der Applikation angeführt.
5.1 Erstellung von Artikeln
Nachfolgend wird das Erstellen von historischen Artikeln mithilfe von Geo-Objekten,
anhand eines konkreten Beispiels, diskutiert. Dabei werden die in Kapitel 3.2.2
vorgestellten Seitentypen im praktischen Zusammenhang behandelt.
In Quelltext 5.1 wird ein Artikel (Austria) gezeigt, in dem verschiedene Seiten-
typen zum Einsatz kommen. Zuerst werden die Landesgrenzen von Austria durch
das Geo-Objekt line definiert (Codezeile 2-18 ). Danach wird zu anderen Artikeln
verlinkt: Salzburg, Mozart und Cities of Austria.
Anhand der Abbildung 5.1 ist ersichtlich, dass es sich bei Salzburg um eine Geo-
Definitionsseite, bei Cities of Austria um eine Geo-Containerseite und bei Mozart
um eine nicht geografische Seite handelt. Aus der Skizzierung ist weiters ersichtlich,
dass City of Austria auf die Geo-Definitionsseiten Graz und Innsbruck verlinkt.
Die verstärkte durchgezogene Linie markiert, welche Artikel auf dem Weltatlas
dargestellt werden.
Abbildung 5.2 zeigt die dazugehörige grafische Darstellung in X3D. Wobei Mo-
zart nicht dargestellt wird, da es sich um eine nicht geografische Seite handelt.
In den nachfolgenden Kapiteln wird näher auf die einzelnen Artikel eingegangen.
84
5 Anwendungsbeschreibung
1 <po in t s>
2 < l i n e de f=” Austr ia ” c o l o r=”0 1 1” t rans=” 0 .3 ”
3 desc=” borders o f Austr ia ” u r l=” ht tp : //www. o e s t e r r e i c h . at ”
4 time=”2007”>
5 <point>
6 < l a t>48.718</ l a t>
7 <long>16.901</ long>
8 </ po int>
9 <point>
10 < l a t>48.814</ l a t>
11 <long>16.540</ long>
12 </ po int>
13 . . .
14 <point>
15 < l a t>48.718</ l a t>
16 <long>16.901</ long>
17 </ po int>
18 </ l i n e>
19 </ po in t s>
20
21 A beau t i f u l c i t y o f Austr ia i s [ [ Sa lzburg ] ] , which i s
22 known f o r the famous composer [ [ Mozart ] ] .
23 Further c i t i e s can be found under [ [ C i t i e s o f Austr ia ] ] .
Quelltext 5.1: Artikel mit geografischem Inhalt (Geo-Objekt) und Verlinkungen
auf weitere Artikel.
5.1.1 Geo-Definitionsseite
Der Wikitext zum Artikel Salzburg wird in Quelltext 5.2 aufgelistet. Dieser bein-
haltet für die Darstellung der Stadt das Geo-Objekt point. Mittels der Definition
des Attributs time wird den geografischen Daten eine zeitliche Information hinzu-
gefügt. Dadurch ist es möglich die einzelnen Geo-Objekte zeitlich anzusprechen.
Das ist für zeitliche Verläufe und der Suche nach Zeitperioden erforderlich.
85
5 Anwendungsbeschreibung
Abbildung 5.1: Verlinkungsbaums für die grafische Darstellung von Austria.
Abbildung 5.2: Grafische Darstellung des Artikels Austria.
86
5 Anwendungsbeschreibung
<po in t s>
<point de f=”Salzburg ” t rans=” 0 .4 ” desc=”Salzburg . . . ”
u r l=”” time=”2000”>
< l a t>47.8001839</ l a t>
<long>13.0427455</ long>
</ po int>
</ po in t s>
Quelltext 5.2: Wikitext der Geo-Definitionsseite Salzburg.
5.1.2 Geo-Containerseite
In Quelltext 5.3 wird die Darstellung der Geo-Containerseite Cities of Austria
aufgelistet. Die dreidimensionale Darstellung wird hier aus den verlinkten Seiten
(Graz und Innsbruck) generiert. Dabei wird jede verlinkte Seite, wie in Kapi-
tel 3.2.3 beschrieben, verarbeitet und die darin definierten Geo-Objekte angezeigt.
Die beiden Geo-Definitionsseiten Graz und Innsbruck beinhalten jeweils das Geo-
Objekt point, siehe Abbildung 5.3.
<points ></points>
[ [ Graz ] ]
[ [ Innsbruck ] ]
Quelltext 5.3: Wikitext der Geo-Containerseite Cities of Austria.
Zeitlicher Verlauf
Durch die Verwendung einer Geo-Containerseite ist es möglich, bestehende Artikel
für einen zeitlichen Verlauf heranzuziehen. In Quelltext 5.4 wird ein Beispiel (His-
tory of Austria) dazu dargestellt. Dieser beinhaltet Links auf die Artikel Austria,
Austria-Hungary 1911, Austria 1935 und Austria 1885.
Abbildung 5.4 zeigt den Verlinkungsbaum für die grafische Darstellung. Durch
das Hinzufügen der beiden Attribute from und until wird ein Zeitintervall defi-
87
5 Anwendungsbeschreibung
Abbildung 5.3: Grafische Darstellung des Artikels Cities of Austria.
niert, siehe Quelltext 5.4 (Codezeile 1 ). Es werden nur jene Geo-Objekte der ver-
linkten Artikel auf dem Weltatlas dargestellt, die sich innerhalb dieses Intervalls
befinden, diese sind Austria, Austria 1911 und Austria 1935. Der Artikel Austria
1885 wird nicht dargestellt, da das Attribut time nicht innerhalb des Zeitbereichs
liegt, siehe Quelltext 5.5 (Codezeile 2 ).
Die Visualisierung des Artikels History of Austria wird in Abbildung 5.5 darge-
stellt.
1 <po in t s from=”1911” un t i l=”2007”></ po in t s>
2
3 [ [ Austr ia ] ]
4 [ [ Austr ia−Hungary 1911 ] ]
5 [ [ Austr ia 1 9 3 5 ] ]
6 [ [ Austr ia 1 8 8 5 ] ]
Quelltext 5.4: Artikel History of Austria mit zeitlichem Verlauf.
88
5 Anwendungsbeschreibung
Abbildung 5.4: Verlinkungsbaum für die grafische Darstellung von History of Aus-
tria.
1 <po in t s>
2 < l i n e de f=” Austr ia 1885” c o l o r=”1 1 0” t rans=” 0 .3 ” desc=”
Austr ia 1885 borders ” u r l=”” time=”1885”>
3 <point>
4 < l a t>48.718</ l a t>
5 <long>16.901</ long>
6 </ po int>
7 . . .
8 <point>
9 < l a t>47.739</ l a t>
10 <long>12.255</ long>
11 </ po int>
12 </ l i n e>
13 </ po in t s>
Quelltext 5.5: Wikitext des Artikels Austria 1885.
89
5 Anwendungsbeschreibung
Abbildung 5.5: Visualisierung des Artikels History of Austria.
5.1.3 Nicht geografische Seite
Auf einer nicht geografischen Seite befinden sich textuelle Informationen mit even-
tuell hinzugefügten zweidimensionalen Abbildungen, wie der Artikel Mozart von
Quelltext 5.1. Dieser beinhaltet kein points-Element und damit auch keine Infor-
mationen für die dreidimensionale Darstellung.
5.2 Navigation
Dieses Kapitel beschreibt die einzelnen Navigationsmöglichkeiten innerhalb der
Benutzerschnittstelle.
5.2.1 X3D-Plug-in
Die Funktionalitäten von X3D-Plug-ins sind je nach Anbieter unterschiedlich. Die
nachfolgende Beschreibung erfolgt anhand des Plug-ins BS Contact VRML/X3D.
90
5 Anwendungsbeschreibung
Abbildung 5.6: Mit dem Kontextmenü eines X3D-Plug-ins können Einstellungen
für die Navigation vorgenommen werden.
[4] Dieses Plug-in wurde bei der Erstellung der Applikation verwendet.
Beim Klick mit der rechten Maustaste ins Plug-in öffnet sich ein Kontextmenü,
siehe Abbildung 5.6. Dieses bietet verschiedene Auswahlmöglichkeiten für den Be-
nutzer an. So kann zwischen unterschiedlichen Viewpoints ausgewählt werden. Da-
bei ist es möglich, diese mittels Viewpoint Tour aufeinander folgend abzuspielen
und zwischen den einzelnen Viewpoints nach vor und zurück zu navigieren (Prev
Viewpoint, Next Viewpoint). Des Weiteren werden verschiedene Darstellungswei-
sen der X3D-Szene (Drahtmodel, Knotenmodel, Festkörper, ...) und eine Auswahl
von unterschiedlichen Bewegungsarten (Movement) angeboten.
5.2.2 Navigationselemente
Durch Slider und Buttons ist ein Navigieren zwischen den einzelnen Geo-Objekten
möglich. Mit den Vorwärts- und Rückwärtsbuttons wird der zeitliche Verlauf schritt-
weise verändert, siehe Abbildung 5.7. Die Anzeige von allen Geo-Objekten ist durch
den Button Show all umgesetzt, mittels des Buttons Animation werden die ein-
zelnen Objekte automatisch in chronologischer Reihenfolge durchlaufen.
91
5 Anwendungsbeschreibung
Abbildung 5.7: Interaktionselemente: Slider und Buttons.
5.2.3 Suche nach Zeitperioden
Durch die Angabe von Zeitperioden kann nach geografischen Objekten mit zeitli-
chem Hintergrund gesucht werden. Dazu ist es erforderlich die beiden Eingabefel-
der from und until auszufüllen. Die Applikation durchsucht alle Artikel um jene
anzuzeigen, die sich innerhalb dieser Zeitspanne befinden. Die Navigation erfolgt,
wie zuvor beschrieben, durch den Slider bzw. den Buttons. In Abbildung 5.8 wird
die Darstellung eines Suchergebnisses gezeigt.
5.2.4 Level of Detail
Durch die Verwendung des LOD-Elements kann detaillierteres Kartenmaterial inte-
griert werden. Dabei wird neben der Definition eines Geo-Objekts zusätzlich das
LOD-Element eingebunden, siehe Quelltext 5.6 (Codezeile 2-19 ). Durch das Attri-
but urlLOD (Codezeile 2 ) wird der Pfad zur einzublendenden Textur definiert. Der
Benutzer muss zuvor das Kartenmaterial über die MediaWiki-Funktionalität Datei
hochladen auf den Server laden. Durch die Angabe von den Koordinaten der vier
Eckpunkte der Karte (Codezeile 3-18 ) ist die Applikation imstande das neue Bild
auf der Weltkugel einzufügen. In Abbildung 5.9 wird dazu ein Beispiel dargestellt.
Das linke Bild zeigt eine X3D-Szene ohne Level of Detail. Im rechten Bild wird der-
selbe Ausschnitt nochmals dargestellt, jedoch mit detaillierterem Kartenmaterial.
Dies wird erreicht, indem der Benutzer eine bestimmte Zoomtiefe erreicht.
92
5 Anwendungsbeschreibung
Abbildung 5.8: Darstellung des Suchergebnisses nach einer Zeitperiode.
Abbildung 5.9: Beispiel einer Verwendung von Level of Detail in einer X3D-Szene.
93
5 Anwendungsbeschreibung
1 <po in t s>
2 <lod urlLOD=”/ wik i / images / Austr ia . jpg ”>
3 <point>
4 < l a t>46 .10</ l a t>
5 <long>9 .35</ long>
6 </ po int>
7 <point>
8 < l a t>46 .10</ l a t>
9 <long>17 .35</ long>
10 </ po int>
11 <point>
12 < l a t>49 .10</ l a t>
13 <long>17 .35</ long>
14 </ po int>
15 <point>
16 < l a t>49 .10</ l a t>
17 <long>9 .35</ long>
18 </ po int>
19 </ lod>
20 < l i n e de f=” Austr ia ” c o l o r=”0 1 1” t rans=” 0 .3 ”
21 desc=” borders ” u r l=” ht tp : //www. o e s t e r r e i c h . at ”
22 time=”2007”>
23 <point>
24 < l a t>48.718</ l a t>
25 <long>16.901</ long>
26 </ po int>
27 . . .
28 </ l i n e>
29 </ po in t s>
Quelltext 5.6: Artikel mit integriertem Level of Detail (LOD).
94
5 Anwendungsbeschreibung
5.3 Technische Voraussetzungen
Die Voraussetzungen zur Installation und Benutzung der Applikation auf Server-
und Clientseite werden in diesem Kapitel näher erläutert.
5.3.1 Anforderungen an die Inbetriebnahme der Applikation
am Server
Installation von MediaWiki
Die Applikation basiert auf MediaWiki Version 1.10.0. Um MediaWiki erfolgreich
zu installieren sind folgende Anforderungen gegeben: [28]
- MediaWiki ist in PHP programmiert, für diese Version ist die Verwendung
von PHP 5 erforderlich.
- Apache oder ISS kann als Webserver eingesetzt werden. Für die Entwicklung
wurde Apache 2 (Version 2.2.3) verwendet.
- Als Datenbank kann MySQL oder PostgreSQL zum Einsatz kommen. Für
die Applikation wurde mit MySQL 5 (Version 5.0.27) gearbeitet.
Nähere Details zur Installation sind unter [29] zu finden.
Erweiterungen
Um die Extension und die Spezialseiten in MediaWiki zu installieren, müssen diese
in der Datei LocalSettings.php, zu finden im Wurzelverzeichnis, angegeben werden,
siehe Quelltext 5.7.
95
5 Anwendungsbeschreibung
r e qu i r e on c e ( ”$IP/ ex t en s i on s /GeoExtension/Point . php” ) ;
r e qu i r e on c e ( ”$IP/ ex t en s i on s /GeoExtension/
GeoExtension . php” ) ;
r e qu i r e on c e ( ”$IP/ ex t en s i on s /GeoExtension/
SearchTimePeriodExtension . php” ) ;
r e qu i r e on c e ( ”$IP/ ex t en s i on s /GeoExtension/
GeoSearchTimePeriodExtension . php” ) ;
Quelltext 5.7: Installation der Erweiterungen: Extension und Spezialseiten.
Bilder hochladen
Das Laden von Bildern in MediaWiki ist standardmäßig deaktiviert. Durch Ände-
rungen in den Konfigurationen kann diese Funktionalität jedoch aktiviert werden.
Nähere Details zu den Einstellungen und zur Verwendung der hoch geladenen
Bilder im Wiki sind unter [26] und [27] zu finden.
5.3.2 Anforderungen an den Client
Betriebssystem
Die Applikation ist unabhängig vom Betriebssystem, da das System als Web-
Applikation konzipiert wurde. Als Entwicklungsumgebung wurde Windows XP
verwendet.
Browser
Der 3D-Atlas kann in allen gängigen Browsern benutzt werden, sofern ein X3D-
Plug-in installiert wird. Für die Entwicklung kam Internet Explorer 7 zum Einsatz.
X3D-Plug-in
Für die Darstellung des X3D-Dokuments ist ein X3D-Plug-in erforderlich. In Ka-
pitel 2.1.5 werden verschiedene Plug-ins vorgestellt. Für die Entwicklung der Ap-
plikation wurde das Plug-in BS Contact VRML/X3D [4] verwendet.
96
6 Schlussfolgerungen
Im Laufe der Arbeit hat sich die Komplexität und Vielseitigkeit dieses Themen-
gebiets herausgestellt, vor allem durch die Kombination unterschiedlicher Tech-
nologien und das Beachten verschiedener Aspekte, die bei der Erstellung eines
historischen Weltatlasses erforderlich sind. Dabei waren Kenntnisse in Web 2.0, in
der Visualisierung von Objekten in X3D und in der Verarbeitung von geografischen
Informationen erforderlich.
Die Herausforderungen lagen unter anderem in der Darstellung der Geo-Objekte
auf einer dreidimensionalen Kugel. Die X3D-Spezifikation bietet spezielle Funktio-
nalitäten (Geospatial-Komponente) für die Visualisierung von geografischen Da-
ten, jedoch gibt es keine Plug-ins, die diese auch in einem Webbrowser unterstützen.
Bei der Weiterentwicklung von X3D-Plug-ins besteht ein großer Nachholbedarf, ob-
wohl Intentionen für eine Implementierung dieser X3D-Funktionalitäten bestehen,
siehe BS Contact Geo.
Die Applikation wurde in ein bestehendes Wiki (MediaWiki) integriert. Dabei
war ein weiteres Kriterium die Generierung einer Struktur für die Darstellung
in X3D aus den Wiki-Daten. Die Verwendung einer Extension ermöglichte das
Einbetten der Daten innerhalb des Wikitexts. Zum Konstruieren komplexer geo-
grafischer Darstellungen wurde auf das Grundprinzip von Wikis, dem Verlinken,
zurückgegriffen. Dabei wird die Visualisierung aus den Inhalten der verlinkten Ar-
tikel generiert.
Eine zukünftige Erweiterung der Applikation besteht in der Erhöhung der Ge-
nauigkeit bei der Darstellung von Geo-Objekten sowie bei der Integration von
detaillierterem Kartenmaterial. Bei ausreichender Unterstützung der X3D-Spezi-
fikation seitens der X3D-Plug-ins, würde eine Restrukturierung des Systems auf
die Geospatial-Komponente höhere Flexibilität bringen. Eine sehr hilfreiche Funk-
tionalität wäre das Integrieren einer Benutzerschnittstelle, die es ermöglicht, die
97
6 Schlussfolgerungen
Koordinaten für Geo-Objekte per Mausklick auf den 3D-Globus einzugeben, an-
statt diese direkt in den Wikitext eintragen zu müssen.
Der X3D-Standard hat sich noch nicht etabliert. Jedoch lassen die unterschiedli-
chen Arbeitsgruppen des Web3D-Konsortiums und den daraus resultierenden Spe-
zifikationen für unterschiedlichen Einsatzgebiete auf eine interessante Zukunft hof-
fen. Projekte wie Wikipedia haben gezeigt, dass durch die Einbeziehung vieler Be-
nutzer eine große Datensammlung geschaffen werden kann. Durch die Verwendung
ähnlicher Technologien kann dieses Potenzial für diese Applikation ausgeschöpft
werden, um eine umfangreiche historische Datenbasis, verknüpft mit geografischen
Informationen, zu erhalten.
98
Abbildungsverzeichnis
2.1 Visualisierung zu den Codebeispielen in VRML und X3D. . . . . . . 7
2.2 Szenegraph zu den Codebeispielen in VRML und X3D. . . . . . . . 11
2.3 X3D-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4 X3D-Basis-Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.5 Visualisierung einer Box . . . . . . . . . . . . . . . . . . . . . . . . 17
2.6 Visualisierung eines Kegels . . . . . . . . . . . . . . . . . . . . . . . 18
2.7 Visualisierung eines Zylinders . . . . . . . . . . . . . . . . . . . . . 20
2.8 Visualisierung einer Kugel . . . . . . . . . . . . . . . . . . . . . . . 21
2.9 Visualisierung eines Material-Knotens . . . . . . . . . . . . . . . . . 23
2.10 Visualisierung eines ImageTexture-Knotens . . . . . . . . . . . . . . 24
2.11 Visualisierung eines Transform-Knotens . . . . . . . . . . . . . . . . 26
2.12 Web 2.0 Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.13 Topologische Beziehungen . . . . . . . . . . . . . . . . . . . . . . . 40
2.14 Kartesische Koordinaten im Vergleich zu Polarkoordinaten . . . . . 41
2.15 Geografisches Koordinatensystem . . . . . . . . . . . . . . . . . . . 42
2.16 Referenzellipsoide nach regionalem Bezug . . . . . . . . . . . . . . . 43
2.17 Google Earth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.18 NASA World Wind . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.1 Ablauf des Visualisierungsprozesses . . . . . . . . . . . . . . . . . . 51
3.2 Architektur von MediaWiki . . . . . . . . . . . . . . . . . . . . . . 52
3.3 Mögliche Verlinkungen ausgehend von einem Artikel . . . . . . . . . 54
3.4 Architektur des technischen Systems mit Integration in MediaWiki. 56
3.5 Ablaufdiagramm für die Abarbeitung der Spezialseite . . . . . . . . 57
3.6 Ablaufdiagramm für die Anzeige einer Wiki-Seite . . . . . . . . . . 60
99
Abbildungsverzeichnis
5.1 Verlinkungsbaums für die grafische Darstellung von Austria. . . . . 86
5.2 Grafische Darstellung des Artikels Austria. . . . . . . . . . . . . . . 86
5.3 Grafische Darstellung des Artikels Cities of Austria. . . . . . . . . . 88
5.4 Verlinkungsbaum für die grafische Darstellung von History of Austria. 89
5.5 Visualisierung des Artikels mit zeitlichem Verlauf . . . . . . . . . . 90
5.6 Kontextmenü des X3D-Plug-ins BS Contact VRML/X3D . . . . . . 91
5.7 Interaktionselemente: Slider und Buttons . . . . . . . . . . . . . . . 92
5.8 Darstellung des Suchergebnisses nach einer Zeitperiode. . . . . . . . 93
5.9 Beispiel einer Verwendung von Level of Detail in einer X3D-Szene. . 93
100
Quelltextverzeichnis
2.1 VRML-Codebeispiel. . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 X3D-Codebeispiel. . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 Spezifikation des Knotens Box mit Beispiel. . . . . . . . . . . . . . 17
2.4 Spezifikation des Knotens Cone mit Beispiel. . . . . . . . . . . . . . 18
2.5 Spezifikation des Knotens Cylinder mit Beispiel. . . . . . . . . . . . 19
2.6 Spezifikation des Knotens Sphere mit Beispiel. . . . . . . . . . . . . 20
2.7 Spezifikation des Knotens Material mit Beispiel. . . . . . . . . . . . 22
2.8 Spezifikation des Knotens ImageTexture mit Beispiel. . . . . . . . . 23
2.9 Spezifikation des Knotens Transform mit Beispiel. . . . . . . . . . . 26
2.10 Spezifikation des Knotens LOD. . . . . . . . . . . . . . . . . . . . . 27
2.11 Spezifikation von ROUTE. . . . . . . . . . . . . . . . . . . . . . . . 28
2.12 Beispiel eines XML-Dokuments. . . . . . . . . . . . . . . . . . . . . 30
2.13 Beispiel eines XSL-Dokuments. . . . . . . . . . . . . . . . . . . . . 32
2.14 Transformiertes X3D-Dokument. . . . . . . . . . . . . . . . . . . . 33
2.15 Beispiel eines GML-Dokuments. . . . . . . . . . . . . . . . . . . . . 44
2.16 Beispiel eines KML-Dokuments. . . . . . . . . . . . . . . . . . . . . 46
3.1 Zeitlicher Verlauf. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.2 Beispiel einer Wikiseite mit geografischen und historischen Daten. . 58
4.1 Beispiel des Geo-Objekts: Punkt. . . . . . . . . . . . . . . . . . . . 62
4.2 Beispiel des Geo-Objekts: Linie. . . . . . . . . . . . . . . . . . . . . 63
4.3 Beispiel des Geo-Objekts: Fläche. . . . . . . . . . . . . . . . . . . . 64
4.4 Registrierung der Callback-Funktion. . . . . . . . . . . . . . . . . . 65
4.5 Funktion renderPoints(). . . . . . . . . . . . . . . . . . . . . . . . . 66
4.6 Integration des X3D-Plug-ins. . . . . . . . . . . . . . . . . . . . . . 67
101
Quelltextverzeichnis
4.7 Definition der Navigation mittels Slider und Buttons. . . . . . . . . 68
4.8 Spezialseite GeoExtension body.php. . . . . . . . . . . . . . . . . . . 70
4.9 Berechnung der kartesischen Koordinaten eines Punkts. . . . . . . . 71
4.10 Transformation der eingegebenen Attribute. . . . . . . . . . . . . . 72
4.11 Vergabe von IDs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.12 Transformation eines Punkts. . . . . . . . . . . . . . . . . . . . . . 73
4.13 Transformation einer Linie. . . . . . . . . . . . . . . . . . . . . . . . 75
4.14 Berechnung der einzelnen Punkte einer Linie. . . . . . . . . . . . . 76
4.15 Verarbeitung bei nicht Definition des LOD-Elements. . . . . . . . . 77
4.16 XSL-Transformation des LOD-Elements. . . . . . . . . . . . . . . . 78
4.17 Definition von Viewpoints im XSL-Dokument. . . . . . . . . . . . . 79
4.18 Geo-Objekt mit dem Attribut time. . . . . . . . . . . . . . . . . . . 80
4.19 Geo-Containerseite mit den Attributen from und until. . . . . . . . 80
4.20 Aufruf der Slider-Funktion. . . . . . . . . . . . . . . . . . . . . . . . 81
4.21 Funktion sliderInit(). . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.22 Funktion changeEvent(). . . . . . . . . . . . . . . . . . . . . . . . . 82
5.1 Artikel mit geografischem Inhalt (Geo-Objekt) und Verlinkungen
auf weitere Artikel. . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.2 Wikitext der Geo-Definitionsseite Salzburg. . . . . . . . . . . . . . . 87
5.3 Wikitext der Geo-Containerseite Cities of Austria. . . . . . . . . . . 87
5.4 Artikel History of Austria mit zeitlichem Verlauf. . . . . . . . . . . 88
5.5 Wikitext des Artikels Austria 1885. . . . . . . . . . . . . . . . . . . 89
5.6 Artikel mit integriertem Level of Detail (LOD). . . . . . . . . . . . 94
5.7 Installation der Erweiterungen: Extension und Spezialseiten. . . . . 96
102
Literaturverzeichnis
[1] Asbeck, Axel und Sebastian Beyl: Stereoskopische Visualisierung des
VRML Subsets von X3D auf der Basis einer DirectX Architektur. Diplomar-
beit, Universität Köln, 2006.
[2] Bartelme, Norbert: Geoinformatik : Modelle, Strukturen, Funktionen.
Springer, Berlin ; Heidelberg [u.a.], 4., vollst. überarb. Auflage, 2005.
[3] Behme, Henning: Das letzte Siebtel - Interaktivität und Anwendungsfelder.
iX Special, (1):6–7, 2007.
[4] Bitmanagement Software GmbH: BS Contact VRML / X3D, BS Con-
tact Geo. http://www.bitmanagement.com/index.de.html, Stand vom
10.02.2008.
[5] Bullard, Len: Extensible 3D: XML Meets VRML, 2003. Online Version:
http://www.xml.com/pub/a/2003/08/06/x3d.html, Stand vom 10.02.2008.
[6] Carey, Rikk: The Virtual Reality Modeling Language Explained. IEEE Mul-
tiMedia, 5(3):84–93, 1998.
[7] Carey, Rikk und Gavin Bell: The annotated VRML 2.0 reference manual.
Addison-Wesley Longman Ltd., Essex, UK, 1997.
[8] de Lange, Norbert: Geoinformatik in Theorie und Praxis. Springer, Ber-
lin; Heidelberg [u.a.], 2., aktualisierte u. erw. Auflage, 2006.
[9] Däßler, Rolf: Das Einsteigerseminar VRML. BHV Verlag, Kaarst, 1999.
[10] Ebersbach, Anja, Markus Glaser und Richard Heigl: Wiki-Tools:
Kooperation im Web. Springer, Berlin, 2005.
103
Literaturverzeichnis
[11] Eibl, Maximilian: X3D-Standard: 3D im Internet. tecChannel, 2001.
http://www.tecchannel.de/entwicklung/programmierung/401713, Stand
vom 10.02.2008.
[12] Elza, Dethe: XML Matters: The Web ain’t just for 2D any mo-
re. 2005. http://www-128.ibm.com/developerworks/web/library/
x-matters43, Stand vom 10.02.2008.
[13] Geroimenko, Vladimir und Chaomei Chen: Visualizing Information
Using SVG and X3D. Springer-Verlag New York, Inc., Secaucus, NJ, USA,
2004.
[14] Google Earth: Erforschen, suchen und entdecken. http://earth.google.
com, Stand vom 10.02.2008.
[15] Google Earth: What is KML? http://earth.google.com/kml/
whatiskml.html, Stand vom 10.02.2008.
[16] Kiehle, Christian: Lokales abstrakt - Geodaten standardisiert integrieren.
iX Magazin für profenssionelle Informationstechnik, Seiten 50–55, Dezember
2006.
[17] Kloss, Jörg, Robert Rockwell, Kornél Szabó und Martin Duch-
row: VRML97 - Der neue Standard fuer interaktive 3D-Welten im World Wi-
de Web. Addison Wesley Longman Verlag GmbH, Bonn, Screen-Multimedia
Auflage, 1998.
[18] Krone, Oliver: Webfähige interaktive 3D-Visualisierung von Proteinstruk-
turen. Diplomarbeit, Universität Osnabrück, 2003.
[19] Kunze, Michael: Verflochtenes Leben Web 2.0 - der nächste Schritt. c´t
Magazin für Computer Technik, (1):174–178, 2006.
[20] Lake, Ron: Introduction to GML Geography Markup Language.
http://www.w3.org/Mobile/posdep/GMLIntroduction.html, Stand
vom 10.02.2008.
104
Literaturverzeichnis
[21] Lange, Christoph: Wikis und Blogs. Planen. Einrichten. Verwalten. C &
L Computer- U. Literaturverlag, 2007.
[22] Löhr, Stefan: Thematische 3D-Kartographie unter Verwendung von Com-
monGIS und Google Earth. Diplomarbeit, Fachhochschule Mainz Fachbereich
Geoinformatik, 2006.
[23] Matsuba, Stephen N. und Alan Hudson: The Xj3D Toolkit:
A Position Paper. http://w3-mmt.inf.tu-dresden.de/web3d2003/
Yumetech-X3D-Tool-PositionPaper.pdf, Stand vom 10.02.2008.
[24] Mayer, Katja: Extended 3D (X3D) - Untersuchung der vom Web3D-
Konsortium vorgelegten Spezifikation zur Erstellung von 3D-Welten in XML.
Diplomarbeit, Fachhochschule Karlsruhe, 2002.
[25] Media Machines: Flux Player. http://www.mediamachines.com, Stand
vom 10.02.2008.
[26] MediaWiki: Manual:Configuring file uploads. http://www.mediawiki.org/
wiki/Manual:Configuring_file_uploads, Stand vom 10.02.2008.
[27] MediaWiki: Manual:Image Administration. http://www.mediawiki.org/
wiki/Manual:Image_Administration, Stand vom 10.02.2008.
[28] MediaWiki: Manual:Installation requirements. http://www.mediawiki.
org/wiki/Manual:Installation_requirements, Stand vom 10.02.2008.
[29] MediaWiki: Manual:Installing MediaWiki. http://www.mediawiki.org/
wiki/Manual:Installing_MediaWiki, Stand vom 10.02.2008.
[30] MediaWiki: Manual:Special pages. http://www.mediawiki.org/wiki/
Manual:Special_pages, Stand vom 10.02.2008.
[31] MediaWiki: Manual:Tag extensions. http://www.mediawiki.org/wiki/
Manual:Tag_extensions, Stand vom 10.02.2008.
[32] MediaWiki: MediaWiki. http://www.mediawiki.org, Stand vom
10.02.2008.
105
Literaturverzeichnis
[33] Microsoft Corporation: IIS Internet Information Services. http://www.
iis.net, Stand vom 22.02.2008.
[34] MySQL AB: MySQL. http://www.mysql.com, Stand vom 22.02.2008.
[35] NIST (National Institute of Standards and Technology): VRML
Plugin and Browser Detector. http://cic.nist.gov/vrml/vbdetect.html,
Stand vom 10.02.2008.
[36] OGC Open Geospatial Consortium: Geography Markup Language.
http://www.opengeospatial.org/standards/gml, Stand vom 10.02.2008.
[37] OIO - Orientation in Objects: XSLT Prozessoren im Überblick. http:
//www.postgresql.org, Stand vom 22.02.2008.
[38] O’Reilly, Tim: What Is Web 2.0, Design Patterns and Business Models
for the Next Generation of Software. http://www.oreillynet.com/pub/
a/oreilly/tim/news/2005/09/30/what-is-web-20.html?page=1, Stand
vom 10.02.2008.
[39] PostgreSQL Global Development Group: PostgreSQL. http://www.
postgresql.org, Stand vom 22.02.2008.
[40] Steinmann, Harald: 3D-Online-Visualisierungen von Geodaten für digitale
Schulatlanten (mit Beispielanwendungen für die geplante interaktive Version
des Schweizer Weltatlas). Diplomarbeit, Hochschule Karlsruhe - Technik und
Wirtschaft Fakultät Geomatik - Studiengang Kartographie und Geomatik,
2006.
[41] The Apache Software Foundation: Apache. http://httpd.apache.
org, Stand vom 22.02.2008.
[42] W3C: Cascading Style Sheets. http://www.w3.org/Style/CSS/, Stand vom
22.02.2008.
[43] W3C: XSL Transformations (XSLT) Version 1.0 W3C Recommendation 16
November 1999. http://www.w3.org/TR/xslt, Stand vom 22.02.2008.
106
Literaturverzeichnis
[44] W3Schools: XSL Language. http://www.w3schools.com/xsl/xsl_
languages.asp, Stand vom 10.02.2008.
[45] Web3D Consortium: VRML97 Functional specification and VRML97
External Authoring Interface (EAI), ISO/IEC 14772-1:1997 and ISO/IEC
14772-2:2004 - Virtual Reality Modeling Language (VRML). http:
//www.web3d.org/x3d/specifications/vrml/ISO-IEC-14772-VRML97,
Stand vom 10.02.2008.
[46] Web3D Consortium: Web3D Consortium Working Groups. http://www.
web3d.org/x3d/workgroups, Stand vom 10.02.2008.
[47] Web3D Consortium: What is X3D? http://www.web3d.org/about/
overview, Stand vom 10.02.2008.
[48] Web3D Consortium: X3D and Related Specifications. http://www.web3d.
org/x3d/specifications, Stand vom 10.02.2008.
[49] Web3D Consortium: X3D-Edit for Extensible 3D (X3D) Graphics -
README. http://www.web3d.org/x3d/content/README.X3D-Edit.html,
Stand vom 10.02.2008.
[50] Web3D Consortium: X3D Specifications, Encodings and Language Bin-
dings, ISO/IEC 19775:2004/FDAM Am1:2006 - X3D Architecture and
base components with Amendment 1, Part 2. http://www.web3d.org/
x3d/specifications/ISO-IEC-19775-X3DAbstractSpecification_+_
Amendment1_to_Part1, Stand vom 10.02.2008.
[51] Web3D Consortium: X3D Specifications, Encodings and Language
Bindings, ISO/IEC CD 19775-1r1:200x - X3D Architecture and base
components Revision 1. http://www.web3d.org/x3d/specifications/
ISO-IEC-19775-X3DAbstractSpecification_Revision1_to_Part1, Stand
vom 10.02.2008.
[52] Web3D Consortium: X3D Tools and Applications. http://www.web3d.
org/tools, Stand vom 10.02.2008.
107
Literaturverzeichnis
[53] Web3D Consortium: Xj3D. http://www.xj3d.org, Stand vom 10.02.2008.
[54] Wikimedia: Help:MediaWiki architecture. http://meta.wikimedia.org/
wiki/Help:MediaWiki_architecture, Stand vom 10.02.2008.
[55] Wilk, Christian: Überlagert - Mit KML Google Earth erweitern. iX Ma-
gazin für profenssionelle Informationstechnik, (12):58–63, Dezember 2006.
[56] Wilk, Christian: Komplexe Nische - GML: geografischer Markup-Standard.
iX Magazin für profenssionelle Informationstechnik, (12):66–68, Dezember
2006.
[57] Wilk, Christian: Welt in Händen - Arbeiten mit Google Earth und World
Wind. iX SPECIAL, (1):69–76, 2007.
[58] Yahoo: Yahoo! UI Library: Slider. http://developer.yahoo.com/yui/
slider, Stand vom 10.02.2008.
108