Diplomarbeit Markus Haßfurter

Diplomarbeit
Markus Haÿfurter
markus@hassfurter.net
Matrikelnummer 1729542
Das automatische Mapping zweidimensionaler

meteorologischer Visualisierungen auf einen
dreidimensionalen Kontext
Betreuer
Prof. Dr.-Ing. Detlef Krömker
Professur für Graphische Datenverarbeitung
Hans Joachim Koppert

Deutscher Wetterdienst
eingereicht am
16. Dezember 2007
Institut für Informatik

Fachbereich Informatik und Mathematik
Johann Wolfgang Goethe Universität
ii
Erklärung
Hiermit erkläre ich, dass die vorliegende Diplomarbeit ohne unzulässige Hilfe
und nur unter Verwendung der angegebenen Literatur angefertigt wurde.
Die Arbeit wurde bisher keiner anderen Prüfungsbehörde vorgelegt und auch
noch nicht veröentlicht.
Oenbach, 16. Dezember 2007
Markus Haÿfurter
iii
iv
Danksagung
Ich möchte mich bei Prof. Dr.-Ing. Detlef Krömker für die Möglichkeit be-
danken, diese Arbeit unter seiner Betreuung schreiben zu können, und bei
Prof. Dr. Rüdiger Brause für die Zusage zur Zweitkorrektur. Ebenso möchte
ich mich bei Hans-Joachim Koppert und Dirk Heizenreder bedanken, die die-
se Arbeit beim Deutschen Wetterdienst ermöglichten. Besonderer Dank geht
auch an Gregor Schnee, der mich mit Rat und Tat unterstützt hat. Natürlich
bedanke ich mich auch bei meiner Familie, meinen Freunden und besonders
bei Isabel Anhäuser, die mich alle bei der Erstellung der Arbeit begleitet und
mir mit Anmerkungen sehr geholfen haben.
v
vi
Kurzfassung
Die hier vorliegende Arbeit handelt von dem automatischen Mapping zweidi-
mensionaler meteorologischer Visualisierungen auf einen dreidimensionalen
Kontext als Bestandteil der meteorologischen Workstation NinJo.
NinJo Die NinJo-Workstation ist ein gemeinsames Software-Projekt des
Deutschen Wetterdienstes, des geophysikalischen Beratungsdienstes der Bun-
deswehr, der MeteoSchweiz, des Dänischen Meteorologischen Instituts und
des Meterological Service of Canada. Mit ihr wird der Meteorologe, Wetter-
berater, Flugwetterberater und Forscher in einem Wetterdienst in die Lage
versetzt, die Wetterlagen zu beobachten, Vorhersagen und Wetterkarten zu
erstellen, Warnungen zu erzeugen und zu überwachen.
Aufgabe Die Arbeit wird im NinJo-Kontext unter Nutzung der vorhan-

denen Frameworks abzuwickeln sein. Entwickelt werden soll eine NinJo--
Komponente zur Visualisierung von meteorologischen Daten in 3D. NinJo
speichert zur Zeit die Daten dreidimensional, visualisiert sie aber nur in
zweidimensionalen horizontalen oder vertikalen Schnitten. Die automatische
Abbildung einer zweidimensionalen auf eine dreidimensionale Darstellung
steht im Vordergrund. Dies wurde so noch nicht in der meteorologischen Ge-
meinschaft versucht. Aktuelle dreidimensionale Visualisierungssysteme sind
eigenständig und haben keine Verbindung zu operationellen Workstation-
Systemen. Entscheidend ist bei dem neuen Ansatz, die richtigen Einstellun-
gen für geeignete Visualisierungsarten, Darstellungsattribute und die räumli-
che Navigation zu nden. Die Darstellung der Isoächen und Volumenkörper
soll im xypKoordinatensystem (Höhenachse entspricht dem Druck in hPa)
sowie im normalen xyzKoordinatensystem möglich sein. Zur Einordnung in
den geographischen Kontext ist eine Darstellung des Terrains als Geometrie
mit zusätzlicher Texturierung über Satellitenbilder nötig. Das Rendering soll
über die vorhandene Szenengraphenkomponente Graphical Object Factory
und die OpenGL-Schnittstelle von NinJo durchgeführt werden. Diese Kom-
ponenten können um zusätzlich benötigte Funktionalitäten erweitert werden.
vii
viii
Abstract
This Master's thesis is about the automatic mapping of two-dimensional me-

teorological visualizations on a three-dimensional context as part of a meteo-
rological workstation.
NinJo The NinJo-Workstation is a common project of the National Meteo-
rological Service of Germany, the Bundeswehr Geoinformation Service, the
National Meteorological Service of Switzerland, the National Meteorological
Service of Denmark and the Meteorological Service of Canada. It is a tool
for forecaster, meteorological consultants, aviation weather consultants and
scientists to observe the current weather conditions, to generate forecasts, to
create maps, to give and to observe warnings.
Assignment This Master's thesis will be implemented as a part of the

NinJo-Workstation and uses its framework. It is about the development of a
component to visualize meteorological data in 3D. Up to now, NinJo has sa-
ved its data in 3D but visualizes only two-dimensional horizontal or vertical
slices.
The focus of this work lies on the automatic mapping of a two-dimensional on
a three-dimensional visualization. This has never been done before in the me-
teorological community. The already existing three-dimensional visualization-
systems are independent and don't have any connection to operating work-
stations. The important part of this work is, to nd the correct settings for a
suitable visualization, attributes and navigation in 3D. The visualization of
isoplanes and volume-bodies should be possible in xyp-coordinates (pressure
instead of height) and normal xyz-coordinates. For better presentation of the
geographical context, satellite images on the topology will be needed.
The rendering will be done by the existing graphical object factory and the
OpenGL-Interface in NinJo. These components have to be edited and new
functionality has to be added.
ix
x
Inhaltsverzeichnis
1 Einleitung 1
1.1 Motivation und Ziel . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Grundlagen 3
2.1 Visualisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1 Was ist der Sinn einer Visualisierung? . . . . . . . . . . 4
2.1.2 Was ist eine gute Visualisierung? . . . . . . . . . . . . 4
2.1.3 Grundlegende Visualisierungstechniken . . . . . . . . . 5
2.2 Volumenvisualisierung . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1 Volumendaten . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.2 Visualisierungspipeline für Volumendaten . . . . . . . . 7
2.2.3 Methoden der Volumenvisualisierung . . . . . . . . . . 7
3 NinJo 15
3.1 Übersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3 Graphical Object Factory . . . . . . . . . . . . . . . . . . . . 20
3.4 Java OpenGL in NinJo . . . . . . . . . . . . . . . . . . . . . . 20
3.5 Visualization for Algorithm Development . . . . . . . . . . . . 21
3.6 Ur-Prototyp . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4 Fachkonzept 23
4.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1.1 Zielsetzung des Fachkonzeptes . . . . . . . . . . . . . . 23
4.1.2 Zielsetzung der Applikation . . . . . . . . . . . . . . . 23
4.1.3 Anforderungen . . . . . . . . . . . . . . . . . . . . . . 24
4.2 Fachliche Grundlagen . . . . . . . . . . . . . . . . . . . . . . . 24
4.2.1 Vorhersagemodelle . . . . . . . . . . . . . . . . . . . . 24
4.2.2 Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2.3 Metadaten . . . . . . . . . . . . . . . . . . . . . . . . . 27
xi
INHALTSVERZEICHNIS
4.2.4 Visualisierung . . . . . . . . . . . . . . . . . . . . . . . 28
4.3 Instant 3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3.1 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3.2 Elemente . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.4 Graphische Benutzungsschnittstelle . . . . . . . . . . . . . . . 33
4.4.1 Applikationsmenü . . . . . . . . . . . . . . . . . . . . . 33
4.4.2 Kontextmenü . . . . . . . . . . . . . . . . . . . . . . . 35
4.4.3 Legende . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.4.4 Werkzeugleisten . . . . . . . . . . . . . . . . . . . . . . 36
4.4.5 Favoriten . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.4.6 Navigation in 3D . . . . . . . . . . . . . . . . . . . . . 38
4.5 Szenarien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.6 Anforderungen an andere Komponenten . . . . . . . . . . . . 42
5 Implementierung 43
5.1 Zusätzliches Hauptfenster . . . . . . . . . . . . . . . . . . . . 43
5.2 Zeichnen in 3D . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.3 Navigation in 3D . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.3.1 Translation und Rotation . . . . . . . . . . . . . . . . 46
5.3.2 Navigieren mit Tastenkombinationen . . . . . . . . . . 49
5.3.3 Zurücksetzen der Navigation . . . . . . . . . . . . . . . 49
5.4 Beleuchtung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.5 Datenreduzierung . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.6 Unterscheidung von 2D- und 3D-Layern . . . . . . . . . . . . 53
5.7 Übergabe von 2D an 3D . . . . . . . . . . . . . . . . . . . . . 53
5.8 3D-Werkzeugleiste . . . . . . . . . . . . . . . . . . . . . . . . 54
5.9 3D-Isoächen . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.9.1 Neues Polygon mit neuer Appearance . . . . . . . . . . 56
5.9.2 Schwellenwerteingabe . . . . . . . . . . . . . . . . . . . 57
5.10 Tiny Cubes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.10.1 Werte-Eingabe . . . . . . . . . . . . . . . . . . . . . . 58
5.11 Höhenprol für Georaster . . . . . . . . . . . . . . . . . . . . 60
5.12 Mapping der Visualisierung . . . . . . . . . . . . . . . . . . . 60
5.12.1 Mapping auf Isoächen . . . . . . . . . . . . . . . . . . 62
5.12.2 Mapping auf Tiny Cubes . . . . . . . . . . . . . . . . . 63
6 Nutzertests 65
6.1 Nutzergruppen . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.2 Methoden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.2.1 Fragebogen . . . . . . . . . . . . . . . . . . . . . . . . 65
6.2.2 Experteninterview . . . . . . . . . . . . . . . . . . . . 66
xii
INHALTSVERZEICHNIS
6.3 Interview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.3.1 Planung und Durchführung . . . . . . . . . . . . . . . 66
6.3.2 Auswertung . . . . . . . . . . . . . . . . . . . . . . . . 67
6.3.3 Interpretation . . . . . . . . . . . . . . . . . . . . . . . 68
6.4 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.4.1 Testplan . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.4.2 Testbogen . . . . . . . . . . . . . . . . . . . . . . . . . 70
6.4.3 Pilottest . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.5 Auswertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.5.1 Quantitative Auswertung . . . . . . . . . . . . . . . . . 71
6.5.2 Qualitative Auswertung . . . . . . . . . . . . . . . . . 71
6.6 Interpretation . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
7 Ausblick 75
7.1 Prioritäten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
7.2 Oene Punkte . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
7.2.1 Visualisierungen . . . . . . . . . . . . . . . . . . . . . . 76
7.2.2 Elemente . . . . . . . . . . . . . . . . . . . . . . . . . 76
7.2.3 Konguration . . . . . . . . . . . . . . . . . . . . . . . 76
7.3 Optionale Punkte . . . . . . . . . . . . . . . . . . . . . . . . . 77
7.3.1 GUI-Elemente . . . . . . . . . . . . . . . . . . . . . . . 77
7.4 Operationeller Betrieb . . . . . . . . . . . . . . . . . . . . . . 77
8 Zusammenfassung 79
Anhang 83
Abbildungsverzeichnis 86
Literaturverzeichnis 89
Fragebögen 91
A Test Nr. 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
B Test Nr. 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
C Test Nr. 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
D Test Nr. 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
E Test Nr. 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
F Test Nr. 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
G Test Nr. 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
H Test Nr. 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Inhaltsverzeichnis CD 109
xiii
INHALTSVERZEICHNIS
xiv
Kapitel 1
Einleitung
1.1 Motivation und Ziel

In der Meteorologie spielt die Darstellung von Daten, die gemessen werden
oder mit Hilfe von komplexen Modellen ausgerechnet werden, eine essentielle
Rolle. Die Auswertung dieser Daten erfolgt durch Meteorologen. Um ihnen
die Arbeit zu erleichtern, wird ihnen durch ein modernes Workstation-System
die Möglichkeit gegeben, die Daten in verschiedenen Visualisierungen und
Kombinationen zu sehen. Leider war dies bis jetzt nur in 2D möglich. In unab-
hängigen Systemen zur dreidimensionalen Darstellung von Wetterdaten hat
sich in der Praxis der Aufwand nicht bezahlt gemacht, den der Meteorologe in
das System investieren muss, um zum Ergebnis zu kommen. Der Aufwand,
einen neuen Rechner zu starten, die Software aufzurufen und alle Einstel-
lungen in der Software zu tätigen, hat den Nutzen einer 3D-Visualisierung
meistens überwogen.
Mit dieser Arbeit wird die dreidimensionale Visualisierung in das bestehende
meteorologische Workstation-System integriert. Ziel dabei ist es, den Meteo-
rologen in die Lage zu versetzen, mit einem Tastendruck von der zweidimen-
sionalen in eine dreidimensionale Darstellung zu wechseln, wenn er auf eine
interessante Wetterlage stöÿt. Die dreidimensionale Ansicht ist standardmä-
ÿig so konguriert, dass der Meteorologe eine für ihn sinnvolle Darstellung
der Daten bekommt, ohne selbst zusätzliche Einstellungen vornehmen zu
müssen. Natürlich bleibt ihm, wenn er in der dreidimensionalen Darstellung
ist, die Möglichkeit, verschiedene Einstellungen zu ändern und das Ergebnis
seinen persönlichen Wünschen anzupassen. Diese Anforderung wurde schon
während der Konzeptionsphase von NinJo durch die Meteorologen gestellt
und soll nun anhand der vorliegenden Arbeit erfüllt werden.
1
KAPITEL 1. EINLEITUNG
1.2 Aufbau
Die Arbeit unterteilt sich in die folgenden Abschnitte, die sich aus der Ent-
wicklung der 3D-Anwendung ergeben haben:
Grundlagen In diesem Abschnitt werden theoretische Grundlagen der Vi-

sualisierung behandelt. Insbesondere stehen die verschiedenen Möglichkeiten
der Visualisierung von dreidimensionalen Daten, wie die Volumenvisualisie-
rung, im Vordergrund.
NinJo Hier wird die allgemeine Funktionsweise der NinJo-Workstation er-

läutert, ihre Architektur vorgestellt und auÿerdem auf das Framework GOF
und die OpenGL-Schnittstelle JOGL genauer eingegangen.
Fachkonzept In diesem Teil wird das Konzept der in dieser Arbeit entwi-
ckelten 3D-Applikation behandelt.
Implementierung Hier werden Besonderheiten und Probleme betrachtet,

die bei der Umsetztzung der 3D-Applikation aufgetreten sind.
Nutzertest Durch die Konzeption, Durchführung und Auswertung der

Nutzertests wird die Applikation evaluiert. Die Ergebnisse nden sich in die-
sem Abschnitt wieder.
Ausblick Es folgt ein Ausblick auf künftige Funktionen der Applikation.
2
Kapitel 2
Grundlagen
2.1 Visualisierung
Denition Visualisierung ist die Bezeichnung für die bildliche Darstellung,
Aufbereitung oder Kommunikation von Informationen. Ebenso handelt es
sich dabei um den Ausdruck für visuelle Wahrnehmung und die bildliche
Vorstellung. Er umfasst alle Arten der bildlichen Repräsentation und der
Sichtbarmachung. Der Begri Visualisierung hat in den letzten Jahren einen
Bedeutungswandel erfahren, so dass damit auch die wissenschaftliche Mo-
dellbildung darunter fällt. Hier werden nicht nur zusätzliche Informationen
dargestellt oder illustriert, sondern komplexe Inhalte vermittelt. Visualisie-
rung spielt aber nicht nur in der Wissenschaft, der Kunst oder der Religion
eine groÿe Rolle, sondern auch im Zusammenhang von sozialer Orientierung
und Identität (zum Beispiel Image-Bildung) und der Repräsentation politi-
1
scher Macht . Verbildlichungen gehören zu einer elementaren Methode von
Darstellung und Verständigung. Dies geschieht in vielen Bereichen wie zum
Beispiel in der Dokumentation, der Sichtbarmachung von Ideen, der Herr-
schaftsausübung (zum Beispiel durch Insignien) oder auch in der Darstellung
von Magie (zum Beispiel durch das Tragen von Masken). Die Erndung der
Fotograe im 19. Jahrhundert ermöglichte es, optische Informationen einfach
zu speichern. Bildschriften wie Zeichen, Icons, Piktogramme oder Symbole
schaen die Voraussetzung, weltweit ohne Hindernisse verschiedener Spra-
chen zu kommunizieren. Nach der Entwicklung elektronischer Technologien
wie Fernsehen, Video- und Computertechnik, kamen im 20. Jahrhundert wei-
tere, bisher unbekannte Möglichkeiten hinzu. Vor allem durch die digitale
Bildbearbeitung wurde eine neue Phase der Visualisierung eingeleitet, da ao
viele neue Möglichkeiten geschaen werden konnten. Jedoch hatte dies eben-
1 siehe Bilder und Macht - Politiker im 20. Jahrhundert [Hop]
3
KAPITEL 2. GRUNDLAGEN
so zur Folge, dass die Glaubwürdigkeit von Bildern in einem gewissen Maÿ
eingeschränkt wurde. (Meyers Lexikon Online [Lex07] )
Der folgende Teil baut auf die Vorlesung Visualisierung von Dr. Ralf Dör-
ner [Dör07] und den begleitenden Folien auf, sowie auf [Enc00], [Enc97] und
[War00].
2.1.1 Was ist der Sinn einer Visualisierung?

Eine Visualisierung kann für verschiedene Zwecke eingesetzt werden. Hierbei
sind die explorative und die konrmative Analyse, aber auch die Präsentation
zu nennen.
Explorative Analyse - Theorie entwickeln Mit Hilfe einer explorativen

Analyse wird aus den vorliegenden Daten eine neue Theorie entwickelt. Durch
die Visualisierung zeigen sich zum Beispiel Zusammenhänge in den Daten,
die neue Erkenntnisse zulassen.
Konrmative Analyse - Theorie überprüfen Im Gegensatz dazu er-

möglicht die konrmative Analyse eine Überprüfung der Theorie anhand der
Visualisierung von Daten.
Präsentation - Informationen vermitteln Mit Hilfe der Präsentation

werden einem Publikum Informationen vermittelt. Durch anschauliche Visua-
lisierungen sind für das Publikum die Informationen aus den Daten leichter
erkennbar.
Alle drei Bereiche sind für Meteorologen und damit auch für diese Arbeit
maÿgeblich.
2.1.2 Was ist eine gute Visualisierung?

Eine Visualisierung ist dann gut, wenn sie ihr Ziel erreicht. Sie soll also
die Analyse von Daten oder Theorien ermöglichen oder unterstützen. Dies
gelingt durch eine geeignete Darstellung der Daten oder Informationen. Au-
ÿerdem soll jede Visualisierung Kriterien der Expressivität, Eektivität und
Angemessenheit erfüllen.
expressiv Eine Visualisierung ist dann expressiv, wenn sie die Informatio-
nen der Daten darstellt, ohne zu Fehldeutungen zu verleiten.
4
2.1. VISUALISIERUNG
eektiv Die Eektivität einer Visualisierung wird daran gemessen, ob die

Informationen der Daten schnell und intuitiv erkannt werden können.
angemessen Eine Visualisierung ist angemessen, wenn ihr Aufwand der

Menge der dargestellten Informationen entspricht.
Auch wenn eine Visualisierung nach den Kriterien der Expressivität, der Ef-
fektivität und der Angemessenheit erstellt wurde, kann letztendlich die Güte
einer Visualisierung nur durch Nutzertests ermittelt werden. Dem wird die
vorliegende Arbeit in Kapitel 6 gerecht.
2.1.3 Grundlegende Visualisierungstechniken

Man unterscheidet zwei Visualisierungstechniken: das Mapping und die Dar-
stellung durch Bilder und Worte.
Im Folgenden werden verschiedene Verfahren vorgestellt, um Daten auf Ob-

jekteigenschaften abzubilden. Diesen Vorgang nennt man Mapping. Man
kann auf verschiedene Eigenschaften mappen.
Geometrie Hier werden die Daten auf geometrische Eigenschaften eines

Objektes gemappt, zum Beispiel auf die Gröÿe.
Helligkeit Bei dieser Methode werden die Daten einer Helligkeitsskala zu-
gewiesen. Dies ist eine sehr eektive Methode. Auch eine Farbfehlsichtigkeit
spielt hier keine Rolle.
Farbe Farbe ist ein sehr breites und komplexes Gebiet, das unter ande-
rem auch die Luminanz beinhaltet. Um auf Farbe zu mappen, wird eine
Farbskala eingesetzt. Da Luminanzunterschiede mit einer wesentlich höhe-
ren Ortsauösung wahrnehmbar sind, können diese Helligkeitsdierenzen für
Details, Kontur und Form eektiv eingesetzt werden. Farbe ist dagegen für
nominale, ordinale und quantitative Wertebereiche eektiv.
Textur Textur ist ein mächtiges Visualisierungsprinzip und dem Mapping

auf Farbe ähnlich, auch in den auftretenden Phänomenen. Auÿerdem ist es
gut mit anderen Techniken kombinierbar. Beim Mapping auf Textur ist zu
5
2
beachten, dass eine Textur nach Gabor drei Dimensionen hat: Orientierung,
Gröÿe und Kontrast. Daten, die mehr Dimensionen haben, können also nicht
alleine auf Textur gemappt werden. Ein Vorteil dieser Art des Mappings
ist, dass aktuelle Grakkarten die Textur unterstützen. Hier entsteht kein
Geschwindigkeitsverlust in der Darstellung.
Objekte Glyphenbasierte Techniken werden häug eingesetzt. Ihr wich-

tigster Vorteil ist, dass sich Ikonen auf der Ebene oder im Raum positionieren
lassen und sich multivariate Daten in mehrdimensionalen Räumen darstel-
len lassen. Die Darstellung der Daten ist sehr kompakt. Ein weiterer Aspekt
besteht darin, dass man mit Glyphen, insbesondere Stick- und Farbikonen,
Texturen erzeugen kann.
Neben dem Mapping gehört die Darstellung durch Bilder und Worte zu
den grundlegenden Visualisierungstechniken.
Graphiken werden für strukturelle Logik, örtliche Strukturen, zur besseren

3
Erinnerung und bei Details für verschiedene Betrachtungszeiten benutzt,
wohingegen Wörter für prozedurale Logik, konditionale Logik und abstrakte
Konzepte benutzt werden.
Die Technik des Mappings auf Textur wird im Rahmen dieser Arbeit einge-
setzt, Mapping auf Geometrie, Farbe und Helligkeit wird in einer späteren
Version der Anwendung verwendet werden. Bilder und Worte werden nur für
die Legenden der Anwendung benutzt.
2.2 Volumenvisualisierung
2.2.1 Volumendaten
Grundlagen Begrisbestimmung Volumendaten werden oft genutzt,
um ein dreidimensionales Bezugssystem mit skalaren Daten zu beschreiben.
Oft haben die skalaren Daten einen Wirkungskreis und sind in einem regel-
mäÿigen Gitter angeordnet. Eine Gitterzelle des Gitters wird Voxel genannt.
Die Beobachtungspunkte eines Gitters können die Zellenmittelpunkte oder
die Gitterpunkte sein.
2 Dennis Gábor (eigentlich Dénes Gábor) (* 5. Juni 1900; † 8. Februar 1979), Nach ihm
ist die Gabor-Transformation benannt, eine örtlich eingeschränkte Variante der Fourier-
Transformation. [Wik07a]
3 Einschränkung: Dies gilt nicht für abstrakte Sachverhalte.
6
2.2. VOLUMENVISUALISIERUNG
2.2.2 Visualisierungspipeline für Volumendaten

Um von den Daten zu einem Bild zu kommen, sind verschiedene Methoden in
einem mehrstugen Prozess notwendig. Dieser Prozess wird Visualisierungs-
pipeline genannt.
1. Volumendaten
2. Filtering
3. Mapping
4. Rendering
5. Bild
Innerhalb des Mappings kann eine Klassikation oder eine Klassikation und
eine Flächenextraktion stattnden.
2.2.3 Methoden der Volumenvisualisierung

Um Volumendaten zu visualisieren, gibt es unter anderem folgende Metho-
den: die Dekompositionsmethoden und die Extraktion von Flächen. Im Fol-
genden werden einige Dekompositionsmethoden vorgestellt.
Dekompositionsmethoden
Bei diesen Methoden werden die Daten in Punkten, Volumenelementen oder
Schichten dargestellt. Die einfachste Variante der Methode ist die Darstellung
der Gitterpunkte als farbige Pixel, die für die vorliegende Arbeit besonde-
re Bedeutung hat und deshalb in Kapitel 5.10 nähere Betrachtung ndet.
Die Variante hat jedoch den Nachteil, dass durch die kleinen Primitive die
Deutung der Daten schwer fällt. Aus dem Grund werden bei den Dekompo-
sitionsmethoden normalerweise gröÿere Primitive, wie Kugeln, Quader oder
Tetraeder gewählt, wobei Tetraeder den Nachteil haben, dass sie eine Rich-
tung indizieren. Im Folgenden werden verschiedene Dekompositionsmetho-
den vorgestellt: die Quadermethode, die transparente Quadermethode und
die Dekomposition in Schichten.
Quadermethode (Tiny Cubes Method) Für jedes Volumenelement

wird ein kleiner Quader bestimmt. Zwischen diesen Quadern wird ein Ab-
stand M belassen, um ins Innere des Volumens schauen zu können. Die Ab-
7
maÿe (δx , δy , δz ) und die Position der unteren linken Ecke der Quader be-
stimmt sich wie folgt:
xmax − xmin
δx = ( )
nx (M + 1) − M
ymax − ymin
δy = ( )
ny (M + 1) − M
zmax − zmin
δz = ( )
nz (M + 1) − M
xi = x0 + iδx (M + 1) und i = 1, ..., nx

yj = y0 + jδy (M + 1) und j = 1, ..., ny
zk = z0 + kδz (M + 1) und k = 1, ..., nz
Jedem Eckpunkt ist ein Farbwert b zugeordnet. Die Quaderächen werden

4
Gouraud-schattiert ausgegeben. (Abbildung 2.1)
Abbildung 2.1: Quadermethode
Transparente Quadermethode (Vanishing Cube Method) Hierbei

werden die Quader mit transparenten Seiten gerendert. Aus je vier Gitter-
punkten werden semitransparente Polygone. Es kann zu Problemen mit der
Sichtbarkeitsbestimmung durch die Verwendung des z-Buers kommen. Aus
diesem Grund ist eine Back-to-Front-Order Ausgabe nötig. (Abbildung 2.2)
4 Gouraud-Schattierung ist eine Methode für eine lineare Interpolation einer Farbe oder
eines Schattens über ein Polygon
8
Abbildung 2.2: Transparente Quadermethode
Dekomposition in Schichten (Slicing) Anstelle der trivariaten Funkti-

on f (x, y, z) werden bivariate Funktionen der Form
fi (y, z) = f (xi , y, z) mit i = 0, ..., (nx + 1)

fj (x, z) = f (x, yj , z) mit i = 0, ..., (ny + 1)
fk (x, y) = f (x, y, zk ) mit i = 0, ..., (nz + 1)
dargestellt. Die Schnittebenen können in der Regel interaktiv ausgewählt und

verschoben werden. Man nennt sie manchmal auch Sweeping Planes. Diese
Methode wird sehr häug genutzt und hat in vielen Anwendungsfeldern eine
lange Tradition (zum Beispiel in der Medizin bei Computertomographien).
(Abbildung 2.3)
Es gibt auch Varianten der Schichtenmethode. Hier werden die Anordnun-
gen der Schnittebenen geändert oder zusätzliche Daten in einem Höhenfeld
kodiert und so ein indirekter Raumbezug hergestellt. (Abbildung 2.4)
Extraktion von Flächen

Neben den Dekompositionsmethoden können Volumendaten ebenso durch die
Extraktion von Flächen visualisiert werden. Typischerweise werden Isoächen
extrahiert, um Positionen eines bestimmten Datenwertes (Schwellenwertes)
erkennen zu können. So werden topologische und geometrische Eigenschaften
oensichtlich. Flächeninhalte oder Volumina können so abgeschätzt werden.
Die Wahl des Schwellenwertes (und damit die Segmentierung) beeinusst
das Ergebnis stark. Diese Wahl ist kritisch, denn es können leicht falsche
9
Abbildung 2.3: Schichtenmethode
Abbildung 2.4: Varianten der Schichtenmethode
Interpretationen suggeriert werden.

Nun werden verschiedene Methoden vorgestellt, um Isoächen zu extrahieren.
Segmentierung und einfache Approximation Nach der Festlegung ei-

nes Schwellenwertes oder eines Schwellenwertintervalls werden drei Klassen
ermittelt:
innen - auf - auÿen
Alle auf -Voxel repräsentieren eine grobe Approximation der Isoäche. Die
Ermittlung von nur zwei Klassen ist numerisch stabiler:
10
innen auÿen
Seitenächen, die einen innen und einen auÿen Nachbarn haben, approxi-
mieren die Isoäche. Bei dieser Methode bleibt allerdings die Voxelstruktur
(Blockstruktur) deutlich sichtbar.
Extraktion von Flächen aus Zellen Wenn Isoächen beliebig innerhalb

einer Zelle verlaufen können, braucht man Methoden, um sie aus einer Zelle
zu extrahieren. Dafür gibt es hauptsächlich folgende Verfahren: Contouring
and Connecting, Marching Cube, Dividing Cube und Marching Tetraeder.
Contouring and Connecting Beim Contouring and Connecting wer-

den als erster Schritt auf parallelen Schnitten eines Datenwürfels zweidimen-
sionale Isolinien extrahiert. Im zweiten Schritt werden dann die benachbarten
Isolinien durch Dreiecksnetze verbunden. (Abbildung 2.5)
Abbildung 2.5: Contouring and Connecting
Das Problem bei verschiedenen Kontur-Topologien auf benachbarten Ebe-

nen ist, dass eine eindeutige Verbindung nicht immer möglich wird. Um dieses
Problem zu beheben, gibt es folgende Möglichkeiten:
• Eine interaktive Nutzereingabe erfolgt, um die Konturen zu spezizie-

ren, die miteinander verknüpft werden sollen.
• Ein Bereich mit Mehrdeutigkeiten wird in Teilbereiche unterteilt. Nun

soll das Problem in den Teilgebieten gelöst werden. (Divide and Con-
quer)
• Es wird eine Kostenfunktion herangezogen, um eine Entscheidung zu

treen.
• Weitere Eigenschaften der Isolinien wie Form, Konvexität oder Orien-

tierung erleichtern die Lösung der Mehrdeutigkeit.
11
Marching Cube Ein Würfel wandert durch den Datenwürfel und un-
terteilt diesen in einzelne Zellen. Die Eckpunkte der Zellen werden anhand
eines Schwellenwertes innerhalb und auÿerhalb der Isoäche klassiziert. Die
Schnittpunkte der Isoäche mit den Zellen werden durch lineare Interpo-
lation ermittelt und dann zur Darstellung der Isoäche verbunden. Da die
Eckpunkte durch Bits repräsentiert werden, gibt es für einen Würfel 256
mögliche Belegungen. Die Belegungen werden durch 15 verschiedene Topo-
logien repräsentiert. Dies reicht allerdings nicht aus, um alle theoretischen
Möglichkeiten abzudecken. Deshalb sind die Fälle 3, 6, 7, 10, 12, 13 aus der
Abbildung 2.6 nicht eindeutig. Trotzdem reicht diese Methode für die meisten
Fälle von visuellen Auswertungen bei groÿen Datensätzen aus. In Fall 3 der
Abbildung 2.6: Fallunterscheidungen beim Marching Cube
Abbildung 2.6 existiert eine Mehrdeutigkeit. Es gibt zwei Möglichkeiten für

die Konstruktion der Kanten. Bei der ersten liegen die zwei Punkte in zwei
verschiedenen Flächen. Die andere Möglichkeit besteht darin, dass die zwei
Punkte zu einer Fläche gehören. Die Lösung einer solchen Mehrdeutigkeit
wäre ein weiterer Datenpunkt in der Mitte der Fläche, der durch Interpola-
tion ermittelt und auch klassiziert wird. Damit wird die Lage der Flächen
eindeutig.
Beim Marching Cube Algorithmus kann es zu folgenden Problemen kom-

men. Bei groÿvolumigen Daten entstehen sehr viele Dreiecke. Daraus folgen
auch ein hoher Speicherbedarf und groÿe Renderzeiten. Die Renderzeiten
können durch die Verwendung von Triangle Strips reduziert werden. Eine
Reduzierung der Anzahl der Dreiecke durch Zusammenfassungen (Simpli-
kation), zum Beispiel anhand der Gröÿe der Dreiecke oder des Unterschiedes
der Flächennormalen, bringt weitere Verbesserungen.
12
Dividing Cube Die Idee von Dividing Cubes besteht darin, anstelle
von Dreiecken Oberächenpunkte zu erzeugen. Dafür sind drei Schritte not-
wendig.
1. Die Zellen werden wie folgt klassiziert:
• Innen-Zelle: Alle in der Zelle präsenten Datenwerte sind kleiner

als der gegebene Schwellenwert.
• Auÿen-Zelle: Alle in der Zelle präsenten Datenwerte sind gröÿer

als der gegebene Schwellenwert.
• Oberächenzelle: Die durch den Schwellenwert spezizierte Isoä-

che schneidet die Zelle.
2. Alle Oberächenzellen werden rekursiv unterteilt und erneut klassi-

ziert. Datenpunkte ermittelt man durch trilineare Interpolation.
3. Oberächenzellen nach dem letzten Unterteilungsschritt werden als Ober-

ächenpunkte aufgefasst. Hierfür berechnet man die Normalen (zum
Beispiel durch Zentraldierenzen).
Marching Tetraeder Bei dieser Methode wandert anstelle eines Wür-

fels ein Tetraeder durch den Datensatz. Dies hat die Vorteile, dass nur drei
Fälle unterschieden werden müssen, maximal zwei Dreiecke pro Tetraeder
auftreten und keine Mehrdeutigkeiten vorkommen. Ein Nachteil der Metho-
de besteht darin, dass ein Resampling auf ein Tetraedergitter nötig ist.
Der Isoächenalgorithmus, der in dieser Arbeit verwendet wird, benutzt Mar-

ching Cube, um Flächen zu extrahieren.
Direkte Darstellung der Datenpunkte als semitransparente Ele-

mente (Volume Rendering)
Neben den Dekompositionsmethoden und der Extraktion von Flächen ist
die direkte Darstellung als semitransparente Elemente eine weitere Methode
der Volumenvisualisierung. Man erhält eine kontinuierliche Darstellung der
Datenwerte, einschlieÿlich verschwommener Grenzen.
Bildraumverfahren (Volume Ray Casting) Beim Bildraumverfahren

wird für jeden Punkt der Bildebene ein Strahl auf das Datenobjekt gesendet.
Dann wird für jedes Volumenelement, den der Strahl auf dem Weg durch
den Würfel durchläuft, die Sichtbarkeit berechnet. Dies zeigt der folgende
Pseudocodeausschnitt.
13
Abbildung 2.7: Volume Rendering
for ( each pixel on image plane ){

for ( each sampling point on associated ray ){
compute contribution to pixel ;
}
}
Objektraumverfahren (Projektionsverfahren) Beim Objektraumver-

fahren wird für jedes Volumenelement des Datenobjektes ein Strahl auf die
Bildebene gesendet. Nun wird die Sichtbarkeit des Volumenelementes anhand
der durchlaufenden Volumenelemente auf dem Weg zur Bildebene berechnet.
for ( each volume element ){

for ( each pixel projected onto ){
compute contribution to pixel ;
}
}
14
Kapitel 3
NinJo
Abbildung 3.1: NinJo Übersicht [EuM07]
3.1 Übersicht
NinJo ist ein komplexes Client-Server-System zur Anzeige von meteorologi-
schen Daten, Modellen und meteorologischen Produkten. Hauptfenster und
mögliche Applikationen können natürlich auch über mehrere Bildschirme ver-
teilt oder aufgeteilt werden. In einem Hauptfenster gibt es standardmäÿig
eine Hauptszene und drei Nebenszenen, wie man in Abbildung 3.2 sieht. In
jeder Szene gibt es verschiedene Layer, die in den Nebenszenen inaktiv sind
und in der Hauptszene konguriert werden können. Die verschiedenen Layer
liegen als Schichten übereinander, wie man in Abbildung 3.3 sieht. Jeden
Layer kann man ein- oder ausblenden oder graduell die Transparenz ein-
stellen. Die Reihenfolge der Layer kann beliebig angeordnet werden, um den
individuellen Ansprüchen des Benutzers zu genügen. Es können beliebig viele
15
KAPITEL 3. NINJO
Abbildung 3.2: NinJo Screenshot
Abbildung 3.3: Layer [Leh03]
Layer zu einer Szene hinzugefügt werden (solange genügend Arbeitsspeicher

zur Verfügung steht). Alle Layer zeigen zeitlich synchronisierte Daten an.
Beispiele für Daten, die in Layern dargestellt werden, sind Gitterdaten (Nu-
merical Weather Prediction, NWP), Geodaten wie Geovektor (zum Beispiel
Grenzen, Flüsse, etc.) und Georaster (Oberächenaufnahmen), Punktdaten
von Wetterstationen, Radardaten, Blitzdaten und viele mehr. Der Client hält
nur Geovektor- und Georasterdaten vor. Alle anderen Daten werden aktuell
vom Server geladen.
Animation Die Animation ist für alle Layer und alle Zoom-Level verfüg-
bar. Mit ihr können sowohl gemessene Daten als auch Vorhersagedaten über
einen gewissen Zeitraum angezeigt werden. Den Zeitraum, die Intervalle und
die Animationsgeschwindingkeit kann der Benutzer einstellen. Es wird sogar
16
3.1. ÜBERSICHT
eine Autoupdatefunktion unterstützt, die während der Animation die Daten

aktualisiert.
Applikationen Neben dem Hauptfenster kann man auch Nebenfenster

aufrufen, um spezielle Daten in einem eigenen Fenster zu betrachten. In die-
sen Nebenfenstern gibt es keine verschiedenen Layer, sondern nur die spe-
ziellen Daten, die hier angezeigt werden. Dafür ist eine erweiterte Benut-
zerschnittstelle möglich, wie zum Beispiel eine gesonderte Navigation. Die
3D-Applikation, um die es in dieser Arbeit geht, ist eine solche Applikati-
on. Andere Beispiele für Applikationen sind Meteogramme, die Daten und
Vorhersagen einer Station zeigen, Cross-Sections, die zweidimensionale, ho-
rizontale Schnitte durch den Datenwürfel anzeigen, oder Soundings, welche
die Radiosondenaufstiege anzeigen. Ein Screenshot einer Cross-Section ist in
Abbildung 3.4 dargestellt.
Abbildung 3.4: Cross-Section
Grascher Editor Unter NinJo ist es nicht nur möglich, sich Daten anzei-
gen zu lassen und Modelldaten zu berechnen, sondern man kann die Daten
auch editieren. So wird zum Beispiel bei der Wettervorhersage der Fron-
tenverlauf, der im Modell berechnet wurde, mit Hilfe des MetObjekt-Layers
angepasst.
Kongurierbarkeit Alle Einstellungen, die man während seiner Arbeit

mit NinJo macht, wie zum Beispiel Art und Anordnung der Layer, Anzahl
der Nebenszenen, Änderungen von Farbtabellen und vieles mehr, können als
Session gespeichert und erneut auf jeden NinJo-Client geladen werden, um
17
KAPITEL 3. NINJO
die Arbeit fortzusetzen. Die meisten Einstellungen können in der graschen

Oberäche vorgenommen werden. Der Benutzer kann auch selbst die XML-
Dateien ändern und dort alle Einstellungen vornehmen.
Einsatz NinJo wird in der Version 1.2 operationelle beim Deutschen Wet-
terdienst in der Wettervorhersage eingesetzt. Zur Zeit wird an der Version
1.3 gearbeitet, in der umfangreiche Redesigns der Frameworks implementiert
werden. Die Applikation, die in dieser Arbeit entwickelt wird, setzt auf dieser
neuen Version auf.
3.2 Architektur
NinJo ist vollständig in Java geschrieben und somit plattformunabhängig.
Mit Hilfe einer Pilotstudie wurde sichergestellt, dass die Verwendung von
Java keine Geschwindigkeitseinbuÿen zur Folge hat. NinJo verfügt über eine
Client- und eine Serverschiene, wie man in Abbildung 3.5 sieht. Auÿerhalb
Abbildung 3.5: NinJo Architektur [Leh03]
dieser zwei Schienen existieren noch externe Systeme, die die NinJo-Server
mit Daten beliefern. Die Server bekommen die Daten über einen Imports-
ervice und geben sie über die NinJo Datenserver an die Clients weiter. Aus
Performancegründen werden die NinJo Datenserver auf mehrere Maschinen
aufgeteilt. Die Kommunikation zwischen Server und Client erfolgt mit IIOP.
IIOP steht für Internet Inter ORB Protocol. Es handelt sich dabei um ein in
18
3.2. ARCHITEKTUR
CORBA (Common Object Request Broker Architecture) deniertes Proto-

koll auf der Basis von GIOP (General Inter-ORB Protocol), mit dem Object
Request Broker (ORB) über das Internet kommunizieren können, um Metho-
denaufrufe von Objekten auf anderen Rechnern durchzuführen. IIOP ist eine
Spezialisierung des abstrakten GIOPs für die Kommunikation über TCP/IP.
GIOP und IIOP wurden in der CORBA-Version 2.0 deniert. Mit Hilfe des
IIOP können die ORBs verschiedener Hersteller miteinander kommunizieren.
[Wik07b]
Abbildung 3.6: NinJo-Client [Leh03]
Der Aufbau des Clients ist in Abbildung 3.6 gezeigt. Die verschiedenen
Layer bekommen ihre Daten über IIOP von den entsprechenden NinJo Da-
tenservern. Auÿerdem besteht die Möglichkeit, Daten von anderen externen
Systemen und vom Alt-System MAP (Meteorologische Anwendungs- und
Präsentationssystem) zu importieren. Alle Layer holen ihre Kongurationen,
auch die, die der Benutzer im laufenden Betrieb eingestellt hat, mit Hilfe
des Cong Frameworks von einem Cong Server. Über das Layer Framework
(PAC - Presentation Abstraction Control) erfolgt die Steuerung der Layer.
Die grasche Ausgabe erfolgt nun mit Hilfe der Graphical Object Factory
(GOF), die im Folgenden näher erläutert wird.
19
KAPITEL 3. NINJO
3.3 Graphical Object Factory

Die GOF ist eine abstrakte Grakschnittstelle. Sie abstrahiert von den tech-
nischen Grak-APIs, insbesondere von Java 2D und Java 3D. Sie bietet eine
Schnittstelle für die Beschreibung der Geometrie und Ausgestaltung gra-
scher Objekte. Unterhalb dieser Schnittstelle und damit für den Anwen-
dungsprogrammierer nicht sichtbar, realisiert sie diese graschen Objekte
durch Factories für die jeweiligen konkreten Grak-APIs. Eine weitere Zu-
ständigkeit der GOF ist die Speicherung der Grakobjekte nach ihrer räum-
lichen Lage und Ausdehnung und, darauf aufbauend, die Realisierung ei-
nes ezienten Picks von Grakobjekten. Die GOF wird ausschlieÿlich von
der Visualisierungsbibliothek (VisLib) verwendet. Die VisLib stellt allgemei-
ne, datenartübergreifende Methoden zur Datenvisualisierung zur Verfügung.
Sie nimmt normalisierte Daten entgegen und zeigt sie mit graschen Ob-
jekten an. Sie stellt verschiedene Arten der Visualisierung zur Verfügung,
zum Beispiel Isolinien, Stationseintragungen und Vektorplots. Mit der GOF-
Schnittstelle können 2D-Grakelemente wie Linien, Flächen und Texte geo-
metrisch beschrieben, ausgestaltet und auf einer 2D-Zeichenäche angeordnet
werden. Das Gleiche ist auch in 3D möglich. Die Anordnung der Elemente
geschieht in einer Baumstruktur, dem sogenannten Szenengraphen. Der Sze-
nengraph ist normalerweise in graphische Layer strukturiert und kann in
einem GUI-Element dargestellt werden. Layer lassen sich in der Darstellung
getrennt voneinander ein- und ausblenden. Die GOF baut auf dem Prin-
zip des Szenengraphen auf. Ein Szenengraph ist eine Baumstruktur, die eine
Szene aus Vektor- und Rastergrakelementen beschreibt. Ein Anwender kann
mit der GOF eine solche Szenenbeschreibung erstellen und anschlieÿend der
GOF zur Darstellung übergeben. Diese Art der Veranschaulichung wird auch
Retained-Mode genannt, da der Szenengraph zurückgehalten wird, bis alle
Elemente beschrieben sind, und erst dann gerendert wird.
(Quelle: Design Visualisierung GOF [Jun02])
3.4 Java OpenGL in NinJo

Java OpenGL (JOGL) ist eine externe OpenGL-Programmbibliothek für die
Programmiersprache Java. Sie wurde von Kenneth Russell und Chris Kline
entwickelt, wird aber nun als Open Source von der Game Technology Group
von Sun Microsystems weiterentwickelt. Um JOGL in den Java-Standard
von zukünftigen Java-Versionen aufzunehmen, sind Sun und SGI eine Part-
nerschaft eingegangen, um die Qualität von JOGL zu verbessern.
Durch JOGL kann ein Java-Programm direkt den OpenGL-Code ausführen.
20
3.5. VISUALIZATION FOR ALGORITHM DEVELOPMENT
Dies wird durch spezielle Java-Wrapperklassen erreicht, die Schnittstellen zu

den nativen OpenGL-Funktionen bereitstellen. Die angebotenen Methoden
führen dabei in der Regel den korrespondierenden nativen C-Code aus. JOGL
wird unter anderem in der Java-Quake-Engine Jake2 von bytonic Software
als OpenGL Renderer eingesetzt.
(Quelle: Wikipedia [Wik07c])
3.5 Visualization for Algorithm Development

Visualization for Algorithm Development (VisAD) ist eine Java Component
Vi-
Library mit dem Ziel, eine interaktive Visualisierung und Analyse für be-
sualisation for Algorithm Development

liebige numerische Daten zu schaen. Der Name VisAD setzt sich aus
zusammen, was Visualisierung für
Algorithmenentwicklung bedeutet. Das System verwendet reinen Java-Code
um Plattformunabhängigkeit zu gewährleisten. Auÿerdem unterstützt es das
gemeinsame Arbeiten und den simultanen Zugri auf Daten für räumlich
verteilte Benutzer. Dieses verteilte Arbeiten ist auf den untersten Leveln
1
des Systems durch die Nutzung von Java RMI verteilten Objekten imple-
mentiert. Das allgemeine mathematische Datenmodell kann an fast jede Art
von numerischen Daten angepasst werden. Die gemeinsame Datennutzung
von verschiedenen Nutzern, verschiedene Datenquellen und verschiedene wis-
senschaftliche Anwendungen werden unterstützt. So wurde das Datenmodell
an viele verschiedene Dateiformate angepasst, wie netCDF, HDF-5, FITS,
HDF-EOS, McIDAS, Vis5D, GIF, JPEG, TIFF, QuickTime, ASCII und viele
mehr. Auÿerdem wird ein allgemeines Display-Modell angeboten, das interak-
tive 3D-Darstellungen, Data Fusion, Multidaten-Darstellung, direkte Mani-
pulation der Daten und virtuelle Realitäten unterstützt. Dieses Modell ist an
2
Java2D und Java3D angepasst worden und kann als ein ImersaDesk Virtual-
Reality-Display verwendet werden. Des Weiteren wird die Datenanalyse und
die Berechnung durch Visualisierungen unterstützt, welche die Berechnungs-
steuerung und andere komplexe Anwendungen unterstützen. Es werden auch
eine groÿe Anzahl von Benutzungsschnittstellen unterstützt, vom einfachen
Datenbrowser bis hin zur komplexen Anwendung.
Im Rahmen dieser Arbeit wird der Isoächenalgorithmus von VisAD benutzt.
[Hib07]
1 Remote Method Invocation (Aufruf entfernter Methoden)

2 Virtual-Reality-Display im Format eines Zeichentisches
21
KAPITEL 3. NINJO
3.6 Ur-Prototyp
Schon in NinJo 0.1 wurde eine Studie angefertigt, die mit Hilfe von Java 3D
und den VisAD-Algorithmen dreidimensionale Isoächen darstellen konnte.
In NinJo 0.8 entwickelte man dann einen ersten Prototypen, der dreidimen-
sionale Daten mit OpenGL renderte. In diesem Rahmen wurden die 3D-
Funktionalitäten in der GOF implementiert. Der Ur-Prototyp konnte schon
Isoächen und die Erdoberäche dreidimensional darstellen. Allerdings wur-
de er in einem eigenen Layercontainer gestartet, hatte keine Verbindung zu
den anderen NinJo-Komponenten und konnte auch die NinJo-GUI nicht nut-
zen. In der vorliegenden Arbeit konnte von den dreidimensionalen Funktionen
der GOF protiert werden, die durch die Entwicklung dieses Prototypen ent-
standen sind. Er war in der aktuellen NinJo-Version allerdings nicht lauähig.
Jedoch konnten einige Funktionalitäten wie die Isoächen- oder Georaster-
darstellung als Grundlagen für diese Arbeit verwendet und auf die aktuelle
NinJo-Umgebung, wie sie NinJo 1.3 bereitstellt, angepasst werden. [Sch04]
[Sch03]
22
Kapitel 4
Fachkonzept
4.1 Einleitung
4.1.1 Zielsetzung des Fachkonzeptes
Die Ziele des Fachkonzeptes sind:
• die fachlichen Grundlagen und Anforderungen für NinJo bezüglich die-

ser Applikation zu beschreiben,
• die Grundlagen für das anschlieÿende Design der Applikation zu liefern,
• die Anforderungen an Datenserver und Querschnitts- und Framework-

Komponenten zu formulieren,
• das GUI zu beschreiben und
• Anwendungsfälle (Szenarien) möglichst vollständig und detailliert zu

benennen.
4.1.2 Zielsetzung der Applikation

Das Ziel der Applikation ist es, Wetterphänomene schneller für Meteorologen
anschaulich machen zu können und interessante Bereiche besser zu erkennen.
Mit Hilfe der Instant3D-Funktion werden dem User umständliche Einstellun-
gen abgenommen, so dass eine für ihn sinnvolle Darstellung der Daten auto-
matisch vom System gewählt wird. Diese kann er dann nach seinen Wünschen
ändern.
23
KAPITEL 4. FACHKONZEPT
4.1.3 Anforderungen
Dieses Kapitel nennt Anforderungen an die Applikation. Es sind insbesondere
solche Anforderungen zu nennen, die für das Verständnis dieses Dokuments
erforderlich sind. Anforderungen, die in der ersten Stufe der Applikation nicht
oder nur teilweise realisiert werden, sind als solche kenntlich gemacht. Hier
sind folgende Anforderungen zu nennen:
• Ziel der 3D-Applikation ist die automatische Abbildung einer zweidi-

mensionalen Szene auf eine dreidimensionale Darstellung.
• Die Darstellung der Isoächen und Volumenkörper soll wahlweise im

xyp-Koordinatensystem (Höhenachse entspricht dem Druck in hPa)
sowie im normalen xyz-Koordinatensystem möglich sein. Diese Unter-
scheidung ist erst in einer späteren Version zu implementieren.
• Zur Einordnung in den geographischen Kontext ist eine Darstellung

des Terrains mit geographischem Kontext wie Grenzen, Flüssen und
ähnlichem sowie mit zusätzlicher Texturierung durch Satellitenbilder
nötig.
• Weitere Daten, die von zwei- auf dreidimensionale Darstellung gebracht

werden können, sind Radardaten, Satellitenbilder und Punktbeobach-
tungen in verschiedenen Höhen. Diese Funktionalitäten werden erst in
späteren Versionen aufgenommen.
• Das Rendering sollte über die bereits vorhandene Szenengraphenkom-

ponente (GOF) und OpenGL-Schnittstelle (JOGL) von NinJo durch-
geführt werden. Diese Komponenten sind gegebenenfalls um zusätzlich
benötigte Funktionalitäten zu erweitern.
4.2 Fachliche Grundlagen

4.2.1 Vorhersagemodelle
Im nun folgenden Abschnitt werden einige Vorhersagemodelle kurz vorge-
stellt. Die Daten aus diesen Modellen werden zur Visualisierung herange-
zogen und sind deswegen für die vorliegende Arbeit grundlegend. Folgende
Modelle werden erläutert: das Globale Modell Europa, das Lokale Modell
Europa und das Lokale Modell Kürzestfrist.
24
4.2. FACHLICHE GRUNDLAGEN
Globales Modell Europa - GME Das GME umspannt die komplette

Weltkugel mit einem Dreiecksnetz. Durch die die Wahl von Dreiecken im
Gegensatz zu Quadraten können Konvergenzen an den Polen vermieden wer-
den. Das GME wird benötigt um die lokalen Modelle zu betreiben, da es die
Informationen an den Randgebieten liefert. [Wet07d]
Abbildung 4.1: GME [Wet07a]
Lokales Modell Europa - LME Das LME hat eine viel höhere Auösung
als das GME. Während ein durchschnittliches Gitterelement des GME eine
2 2
Fläche von 3100 km hat, sind die Grundächen des LME 49 km groÿ. In der
Höhe ist diese Auösung nicht notwendig. Hier werden 42 Schichten unter-
schieden, wobei von NinJo nur die unteren 36 ausgewertet werden. Insgesamt
besteht es aus 665 x 667 x 36 Punkten. [Wet07c]
Lokales Modell, Kürzestfrist - LMK Das LMK wurde entwickelt, um

mit seiner hohen Auslösung Vorhersagen für kurze Zeiträume zu machen. Es
bedeckt Deutschland und die Grundäche seiner Gitterelemente beträgt 7,84
2
m . Das Modell hat 421 x 461 x 50 Gitterpunkte. [Wet07b]
4.2.2 Daten
Das Kapitel beschreibt Struktur, Ausprägungen und Formate der Daten
(Gitter-, Punkt-, Vektor-, Raster- und Radardaten) dieser Applikation.
25
Gitterdaten Auf den Gitterdaten liegt der Fokus der 3D-Applikation. Sie
werden mit 3D-Isoächen, Volumendarstellung oder Cross-Sections visuali-
siert. Gitterdaten liegen als dreidimensionales Gitter über der Erdoberä-
che vor. Die Daten werden von Vorhersagemodelle berechnet. Für die 3D-
Anwendung sind die wichtigsten Modelle das GME, das LME und das LMK
wie zuvor beschrieben. Zu jedem Gitterpunkt sind Daten und Koordinaten
gespeichert. Man unterscheidet unterschiedliche Arten von Koordinaten, wie
Druckächen und Modellächen. Druckächen sind von der Topographie un-
abhängig, verändern sich aber zeitlich. Modellächen benden sich in einem
bestimmten Abstand zur Oberäche, folgen also der Topographie. Einige
Wetterelemente werden nur in gewissen Koordinaten angezeigt. Besondere
Modellächen sind Bodenwerte wie 0 m, 2 m oder 10 m über der Bodenober-
äche, die in dieser Arbeit von den Modellächen getrennt werden, da hier
zum Teil Wetterelemente betrachtet werden, die in den übrigen Modellächen
nicht vorhanden sind.
Punktdaten Punktdaten werden in verschiedenen Layern benutzt (Scit- ,

1
2
Blitz-, Straÿenwetter- und Radiosondenlayer ). In der 3D-Applikation werden
sie nur als Textur für die Bodenebene benutzt. In einer späteren Version kann
man auch hier Daten dreidimensional darstellen (zum Beispiel Niederschlag
als 3D-Säulen).
Vektordaten Vektordaten werden im Geovektorlayer

3
und im Trajektori-
4
enlayer genutzt. Die Daten aus dem ersteren nutzt man hier nur im Rahmen
der Texturierung der Bodenebene. Die Trajektorien können in einer späteren
Version der 3D-Applikation ebenfalls dreidimensional dargestellt werden.
Rasterdaten Rasterdaten, wie Satellitenbilder oder Daten aus dem Geo-

rasterlayer, werden ebenfalls im Rahmen der Texturierung der Bodenebene
genutzt. Durch die Farbtabelle GTOPO30, mit der jeder Höhe eine bestimm-
te Farbe zugewiesen wird, können dem Georasterlayer dreidimensionale In-
formationen entnommen werden.
Radardaten In Zukunft werden Radardaten in 3D angeboten. Dann kön-

nen sie auch dreidimensional in der 3D-Applikation dargestellt werden. Die
1 Layer zur Anzeige von Gewitterzellen

2 Layer zur Auswertung von Wetterballonaufstiegen
3 Layer Anzeige von Landesgrenzen, Flüssen und ähnlichem
4 Layer zur Anzeige der Luftbewegungen
26
Radardaten werden allerdings nicht in den bisher betrachteten Gitterkoor-

dinaten geliefert. Die Radarstation macht sogenannte Sweeps, in denen sie
mit einem kegelförmigen Strahl Umläufe in verschiedenen Winkeln macht.
Die einzelnen Sweeps und die der anderen Radarstationen werden dann zu
Komposits zusammengefügt. (Quelle: [Wet07e])
Abbildung 4.2: Radarprinzip [Wet07e]
4.2.3 Metadaten
Metadaten beschreiben, klassizieren und charakterisieren die zuvor beschrie-
benen Datensätze. Sie umfassen zum Beispiel Informationen wie Modelllauf
oder Messzeit, Vorhersagezeitpunkt oder Wertebereich.
Metainformationen können an verschiedenen Stellen und in unterschiedlichen

Formen zusammen mit den Rohdaten auftauchen:
• kodiert im Dateinamen, zum Beispiel Modelllaufzeiten und Element-

namen,
• in Attributverzeichnissen bei speziellen Datenformaten, zum Beispiel

bei GRIB und netCDF,
• in Tag-Feldern oder Headern, zum Beispiel bei Bilddaten und
• in gesonderten, beschreibenden Dateien.
27
Für die fachliche Spezikation ist es notwendig, die relevanten Metadaten

vollständig und einheitlich zu beschreiben, auch wenn sie aus ursprünglich
verschiedenen Quellen kommen oder über die Rohdaten verteilt sind. Die
einheitliche Beschreibung hat den Zweck, die Metadaten komplett auf den
Client laden zu können, bevor auf die eigentlichen Daten zugegrien wird.
Dadurch ist eine gezielte Auswahl von Datensätzen im GUI des Clients erst
möglich.
Die 3D-Applikation stellt die Daten von vorhandenen Layern dreidimensional

dar. Sie nutzt keine neuen Daten, sondern die Metadaten der vorhandenen
5
Layer (zum Beispiel NWP-Layer )
4.2.4 Visualisierung
Dieses Kapitel beschreibt alle Formen der Visualisierung der Datenarten der
Applikation und geht dabei auch auf Details und Ausgestaltungsarten ein.
Für die dreidimensionale Darstellung der Daten werden folgende Visualisie-
rungen genutzt:
3D-Isoächen werden bei der Darstellung von Gitterdaten angewendet.

Sie sind das am häugsten benutzte Mittel zur Darstellung dreidimensiona-
ler Daten. Es können auch mehrere Isoächen für ein Wetterelement durch
mehrere Schwellenwerte gezeigt werden. Durch transparente Darstellung der
äuÿeren Isoächen können so zusätzliche Informationen dargestellt werden.
Siehe Abbildung 4.3.
Vektordarstellungen werden bei der Darstellung bestimmter Gitterdaten

angewandt. Sie sind nur bei Daten, die eine Richtung haben, sinnvoll. Ein
Beispiel für die Vektordarstellung ist die Veranschaulichung von Wind. Siehe
Abbildung 4.4.
Volumendarstellung wird bei der Darstellung von Gitterdaten benötigt.

Sie ist besonders dann sinnvoll, wenn das Innere eines Volumens von Interesse
ist. Das ist zum Beispiel bei der Visualisierung von Wolkenvereisung der Fall.
Ein einfaches Beispiel für die Volumendarstellung mit Hilfe von Tiny Cubes
zeigt Abbildung 4.5.
5 Numerical Weather Prediction-Layer. Dieser Layer stellt Gitterdaten dar.
28
Schatten können bei allen Visualisierungen verwendet werden. Sie erleich-

tern eine Georeferenz. Sie können auf den Boden oder auf eine Wand der
Szene geworfen werden, um den räumlichen Bezug oder die Höhe besser zu er-
kennen. Die Abbildung 4.6 zeigt eine Cross-Section des Geopotentials bei 300
hPa entlang der Y-Achse und der Windgeschwindigkeit entlang der X-Achse
des Modells. Integriert in die 3D-Visualisierung ist die Windgeschwindigkeit
als 3D-Isoäche.
Cross-Section ist keine dreidimensionale, sondern eine zweidimensionale

Visualisierung, die in die dreidimensionale Darstellung eingebettet wird. Es
existieren verschiedenen Ausprägungen, nämlich vertikale und horizontale
Cross-Sections. Sie stellen einen Schnitt durch ein Volumen dar. Abbildung
4.6 zeigt beiden Möglichkeiten.
3D-Isoächen, Volumendarstellung und Cross-Sections wurden schon im Grund-

lagenteil im Abschnitt 2.2 vorgestellt
29
Abbildung 4.3: Isoächen 3D
Abbildung 4.4: Vektordarstellung [aIVG07a]
30
Abbildung 4.5: Volumendarstellung
Abbildung 4.6: 3D-Cross-Section mit Schatten [aIVG07b]
31
4.3 Instant 3D
Hier wird beschrieben, wie auf Knopfdruck automatisch aus einer zweidimen-
sionalen eine dreidimensionale Visualisierung erzeugt wird und bei welchen
Daten bestimmte Standardvorgaben benutzt werden.
4.3.1 Mapping
Das automatische Mapping erfolgt anhand der im 2D-Modus ausgewähl-
ten Wetterelemente. Es wird in einer Kongurationsdatei eine Zuordnung
von Wetterelementen auf 3D-Visualisierungen hinterlegt. Beim Start der 3D-
Applikation wird eine Abfrage der Kongurationsdatei durchgeführt und die
Wetterelemente werden in der entsprechenden dreidimensionalen Visualisie-
rung, mit einer für das Element und die Visualisierung passenden Voreinstel-
lung, angezeigt.
4.3.2 Elemente
Anhand der folgenden Abbildungsvorschrift werden nun den Wetterelemen-
ten passende Visualisierungen zugewiesen.
Niederschlag (Regen) Die Niederschlagsmenge des Regens kann in spä-

teren Versionen dreidimensional dargestellt werden, indem sie als Höhenin-
formation interpretiert und mit Hilfe von Isoächen dargestellt wird. In einer
ersten Version der 3D-Anwendung wird der Niederschlag als Bodenwert und
2D-Isolinie auf die Oberäche gezeichnet.
Niederschlag (Schnee) Für den Niederschlag in Form von Schnee gilt

ähnliches wie für den Niederschlag als Regen. Bei Schnee kann man jedoch
echte Höhenangaben wie Gesamtschneehöhe und Neuschneehöhe darstellen.
Auch dies wird jedoch erst in einer zukünftigen Version geschehen.
Luftdruck Der Luftdruck wird in einem xyz-Koordinatensystem als 3D-

Isoäche mit dem Standardschwellenwert 850 hPa visualisiert.
Temperatur Als Standardvisualisierung wird die 3D-Isoächen-Darstel-

◦
lung gewählt. Als Standardschwellenwert gilt 0 C.
Wind Als Standardvisualisierung wird die Vektoren-Darstellung angewen-

det und die Stärke der Windvektoren auf die Linienbreite der Pfeile gemappt.
Besonders starke Winde werden zusätzlich farblich hervorgehoben.
32
4.4. GRAPHISCHE BENUTZUNGSSCHNITTSTELLE
Relative Feuchte Als Standardvisualisierung wird die Volumen-Darstel-

lung gewählt. Hier ist der Bereich zwischen 90% und 100% hervorzuheben.
Bewölkung Als Standardvisualisierung ndet eine 3D-Isoächen-Darstel-

lung mit einem Schwellenwert von 80% Verwendung.
Höhe der Tropopause und der maximalen Windgeschwindigkeit

Standardvisualisierung ist hier ebenfalls die 3D-Isoächen-Darstellung. Mög-
lich ist eine Visualisierung im xyp- oder im xyz-Koordinatensystem.
Geopotentielle Höhe Als Standardvisualisierung werden 2D-Isolinien auf

p-Flächen angezeigt. Dies ist ein Spezialfall einer Cross-Section.
Gaskonzentrationen (Schichtgrenzen) Als Standardvisualisierung wird

die Isoächen-Darstellung angewendet. Hier sind bestimmte Schwellenwerte
für die jeweiligen Gaskonzentrationen vorgegeben.
Radardaten Als Standardvisualisierung wird die 3D-Isoächen-Darstel-

lung benutzt.
4.4 Graphische Benutzungsschnittstelle

4.4.1 Applikationsmenü
Das Kapitel beschreibt das Applikationsmenü der Anwendung. Dies geschieht
auf der Grundlage der Fachkonzepte zum Layercontainer und zum GUI Look
and Feel. Auf die beiden Dokumente kann aus Lizenzgründen jedoch nicht
näher eingegangen werden. Zusätzlich sind sie für diese Arbeit nur bedingt
relevant.
Menü Das Applikationsmenü besteht aus den folgenden Punkten.
Daten Darstellung Datenreduzierung Einstellungen
Daten Hier kann das angezeigte Element oder dessen Darstellung geän-
dert werden. Bei der Darstellung kann aus Druckächen oder Modellächen
ausgewählt werden. Die Modellächen teilen sich in den Leveltyp 109 (Ne-
benächen) und den Leveltyp 110 (Hauptächen) auf. Die Datenauswahl ist
in Abbildung 4.7 zu sehen.
33
Abbildung 4.7: Datenauswahl
Darstellung Man kann zwischen den verschiedenen Visualisierungen, die

für das Element möglich sind, wählen.
Datenreduzierung Damit lässt sich eine zwei- bis vierfache Datenredu-

zierung einstellen, oder die Datenreduzierung deaktivieren.
Einstellungen Hier lassen sich einige Einstellungen zur Legende, zur Popup-
Info und zu den Linienattributen vornehmen.
34
4.4.2 Kontextmenü
Dieser Abschnitt beschreibt das Kontextmenü des Layers, das heiÿt ein Menü,
das beim Klick mit der rechten Maustaste in der Szene erscheint. Als Kon-
text wird der Punkt der Oberäche genommen, auf dem sich der Mauszeiger
bendet. Ein Mausklick über die Erdoberäche in das Volumen ist nicht
vorgesehen, da es nur bedingten meteorologischen Nutzen hat. Zur besseren
Orientierung wird über dem Mauszeiger (Kreuz) auf der Oberäche noch eine
Säule angezeigt. Das Kontextmenü selbst hat keine 3D-spezischen Funktio-
nen.
Abbildung 4.8: Kontextmenü-Maus
4.4.3 Legende
Die Legende, die standardmäÿig vom Gridlayer gezeigt wird, gibt Informa-
tionen zum aktuellen Element, zum Modelllauf und anderen Daten aus der
Datenauswahl. Zusätzlich müssen nun die aktuellen Visualisierungseinstel-
lungen eingeblendet werden.
35
Abbildung 4.9: Kontextmenü
4.4.4 Werkzeugleisten
Allgemeine Werkzeugleiste Da bei NinJo Navigationsicons, wie zum
Beispiel Zoom, in der allgemeinen Werkzeugleiste liegen, wird diese, wenn sich
NinJo im 3D-Modus bendet, um einige Navigationsfunktionen erweitert. In
Abbildung 4.10 werden einige dieser Funktionen vorgestellt.
Abbildung 4.10: Werkzeugleiste
Die in Abbildung 4.10 nummerierten Icons haben folgende Funktionen:
1 Blick senkrecht auf die Oberäche
2 Blick aus Norden auf die Oberäche
3 Blick aus Osten auf die Oberäche
36
4 Blick aus Süden auf die Oberäche
5 Blick aus Westen auf die Oberäche
Layer-Werkzeugleiste Die layer-spezischen Werkzeugleiste der 3D-Ap-

plikation leitet sich von der Werkzeugleiste des Gridlayers ab. Folgende Ele-
mente des Layermenüs sind auch in der Werkzeugleiste der 3D-Anwendung,
wie Abbildung 5.8 zeigt.
Datenauswahl
Attribute ändern
Visualisierung mit Isolinien (2D-Schnitt)
Visualisierung mit 3D-Isoächen
Visualisierung mit Tiny Cubes
Visualisierung mit Vektoren
Schatten an / aus
Farbtabelle laden oder ändern
Modell ändern
Modelllauf ändern
Abbildung 4.11: 3D-Werkzeugleiste
4.4.5 Favoriten
Man kann die Einstellungen in der 3D-Applikation als einen Favoriten spei-
chern und beim nächsten Start auswählen, so dass NinJo direkt im 3D-Modus
mit den zuletzt ausgewählten Wetterelementen und den benutzerdenierten
Visualisierungen und Einstellungen startet. Für spezielle Ansichten, um zum
Beispiel die Wolkenvereisung darzustellen, ist es sinnvoll, solche Favoriten zu
erstellen.
37
Abbildung 4.12: Favoriten
4.4.6 Navigation in 3D
Trackballfunktionen der Maus Die Navigation in der 3D-Szene erfolgt
durch die Maus. Mit der linken Maustaste kann die Szene gedreht werden,
mit der rechten Maustaste wird die Szene verschoben und mit dem Mausrad
ist ein Zoomen möglich. Durch zusätzliches Drücken von Tasten können fol-
gende zusätzliche Funktionen angesteuert werden:
Tastatur
Ctrl + Maus = Kippen

Shift + Maus = Rotieren
+, - = Zoom
Maus
Mausrad = Zoom
ALT+Mausrad = Objekte aufschneiden
rechte Maustaste = Kontextmenü
38
4.5. SZENARIEN
Auÿer diesen Funktionen ist eine Navigation über eine Navigationseinheit

in der Szene möglich. Mit Hilfe des Legendframeworks ist es möglich, ein
Steuerpanel für die Steuerung mit der Maus einzublenden. Das Legendfra-
mework erlaubt es auch, dieses Element als transparenten Overlay auf das
Hauptfenster zu legen, so dass zur Steuerung kein zusätzlicher Platz für ein
Nebenfenster notwendig ist.
Abbildung 4.13: Navigation [Goo07]
Objekte aufschneiden Wenn in einer Szene mehrere Isoächen gezeigt

werden, zum Beispiel dadurch, dass ein Element mit mehreren Schwellen-
werten visualisiert wird, dann kann es dazu kommen, dass Isoächen nicht
zu sehen sind, weil sie von anderen Isoächen eingeschlossen werden. Um
dieses Problem zu beheben, kann man solche Objekte aufschneiden, indem
man eine unsichtbare Ebene verschiebt und somit wird alles zwischen die-
ser Ebene und der Kameraposition transparent gezeichnet. Die Steuerung
der Ebene ist durch das Drehen des Mausrades bei gedrückter ALT-Taste
aktiviert. Abbildung 4.14 verdeutlicht die Funktion.
4.5 Szenarien
In diesem Abschnitt wird erläutert, wie sich die Applikation in charakteris-
tischen Szenarien verhält. Diese dienen der Veranschaulichung des dynami-
39
Abbildung 4.14: Objekt Aufschnitt
schen Verhaltens der Applikation. Sie können auch als Grundlage von Test-
fällen dienen.
Szenario Nr. 1: Starten der Applikation

Durch ein Icon in der Werkzeugleiste des Hauptfensters wird ein neu-
es Fenster mit der 3D-Applikation gestartet. Der Kartenausschnitt,
der Beobachtungszeitraum und alle Layer mit den jeweiligen Einstel-
lungen werden in die 3D-Ansicht übernommen. Layer, die keine 3D-
Visualisierung haben, werden als zweidimensionale Bodentextur darge-
stellt. Für Layer, die dreidimensional darstellbar sind, wählt das auto-
matische Mapping eine geeignete Visualisierung aus und setzt die ent-
40
4.5. SZENARIEN
sprechenden Schwellenwerte. Die Kamera blickt von Süden nach Nor-

◦
den mit einem Winkel von 45 auf die Erdoberäche.
Szenario Nr. 2: Navigieren in der Applikation

In der dreidimensionalen Szene kann man mit gedrückter linken Maus-
taste den Geokontext ändern, sich also auf der Erdoberäche bewegen.
Durch zusätzliches Drücken der Shift-Taste wird die Szene gekippt,
durch Drücken der Strg-Taste kann die Szene rotiert werden. Mit dem
Drehen des Mausrades wird die Szene vergröÿert oder verkleinert. Mit
Hilfe der Navigationsbuttons kann die Szene nach den verschiedenen
Himmelsrichtungen ausgerichtet werden.
Szenario Nr. 3: Wechseln der Visualisierung

Nachdem das automatische Mapping die Visualisierung der 3D-Szene
gewählt hat, kann der Benutzer die Visualisierung ändern. Mit den
Icons auf der Werkzeugleiste des Layers kann für jeden Layer die Vi-
sualisierung einzeln verändert werden.
Szenario Nr. 4: Wechseln der Daten

Das Wechseln der Daten ist auch in der 3D-Anwendung möglich. Wenn
in einem Layer neue Daten ausgewählt werden, bleibt die Visualisierung
erhalten. Nur wenn der Nutzer einen neuen Layer hinzufügt, wird für
diesen das automatische Mapping aktiviert.
Szenario Nr. 5:
Auswirkungen auf das Hauptfenster
Änderungen des Geokontext und der Zeit wirken sich auf auf das Haupt-
fenster aus. Andere Änderungen, wie das Hinzufügen oder Löschen von
Layer, Änderungen der Visualisierung der Layer oder Einstellungen von
Visualisierungen, werden nicht in das Hauptfenster übernommen.
Szenario Nr. 6: Beenden der Applikation

Wenn das Fenster mit der 3D-Applikation geschlossen wird, wird der
Geokontext und die Zeit in den 2D-Modus übernommen und das 2D-
Fenster tritt in den Fokus.
Screenshots Abbildung 4.15 zeigt, wie ein Screenshot von der fertigen
Anwendung aussehen könnte. Es wird eine vertikale Cross-Section über den
Alpen gezeigt, die den vertikalen Wind darstellt.
41
Abbildung 4.15: Screenshot [aIVG07b]
4.6 Anforderungen an andere Komponenten

In diesem Abschnitt werden Anforderungen an andere Komponenten doku-
mentiert, die sich während der Erstellung dieses Fachkonzeptes ergeben ha-
ben.
Anforderungen an die Grakausgabe Die wichtigste Komponente, an

die in dieser Arbeit eine Anforderung gestellt wird, ist die Grakausgabe.
Um eine Visualisierung von dreidimensionalen Daten zu ermöglichen, ist es
notwendig, dass die GOF eine JOGL-Schnittstelle zur Verfügung stellt.
Anforderungen an die Presentation Application Control (PAC)

Die PAC muss um die Möglichkeit erweitert werden, zweidimensionale und
dreidimensionale Szenengraphen zu unterscheiden.
42
Kapitel 5
Implementierung
Im Folgenden wird die Programmierung der Applikation auf der Grundlage

des Fachkonzeptes erläutert. Es wird auf die Umsetzung der verschiedenen
Funktionen und Abweichungen vom Fachkonzept eingegangen. Es werden
Schritt für Schritt alle Komponenten besprochen, die für die fertige Applika-
tion notwendig sind.
5.1 Zusätzliches Hauptfenster

Als erster Schritt muss ein neuer Knopf in die Werkzeugleiste des Hauptfens-
ters integriert werden, der ein neues Fenster önet, das über einen 3D-fähigen
Canvas, in diesem Fall einen JOGL-Canvas, verfügt. Es bedarf demnach in
MainwindowToolbar1
createAdditionalOptionButton
der Klasse eines neuen AbstractButtons, der mit Hil-
2
fe der Methode erstellt wird. Anschlieÿend
wird in der Klasse MainwindowViewImpl dem neuen Button ein Icon und
show3DWindow
ein Event zugeordnet. Wenn dieses Event eintritt, der Button also gedrückt
wurde, wird die Methode aufgerufen, die eine in einer ab-
gespeicherten Konguration liegende Session startet. In der Konguration
dev_threeD sind unter anderem die Layer gespeichert, die beim Start gela-
den werden sollen. Ebenso verhält es sich mit dem Canvas-Typ, der in diesem
Fall besonders wichtig ist, da hier hinterlegt wurde, von welcher Art der zu
ladende Canvas ist. Es wird Canvas-Typ 3 gewählt, was einem JOGL-Canvas
entspricht.
1 Klassennamen werden monospaced dargestellt

2 Methodennamen werden kursiv dargestellt
43
KAPITEL 5. IMPLEMENTIERUNG
Benutzte Dateien:
\src\org\ninjoworkstation\client\appl\mainwindow\
MainwindowViewImpl.java
\gui\MainwindowToolbar.java
\installation\development\client\remote_config
\cfg\system\default\
\ninjo.client.appl.lc\dev_threeD.xml
\ninjo.client.appl.lc.view\dev_threeD.xml
\ninjo.client.appl.mainwindow\dev_threeD.xml
\ninjo.fwk.client\dev_threeD.xml
Abbildung 5.1: Secondary Mainwindow
44
5.2. ZEICHNEN IN 3D
5.2 Zeichnen in 3D
Nachdem ein zweites Hauptfenster mit einem JOGL-Canvas erzeugt ist, wird
im nächsten Schritt ein dreidimensionales Objekt gezeichnet. Hierfür muss in
der Klasse CanvasImplJOGL ein solches Objekt erzeugt und gerendert wer-
den. Auÿerdem wird die Kameraposition und der Blickwinkel festgelegt. Als
Beispielobjekt wird hier eine Gitter-Teekanne gewählt. Zum Zeichnen wurden
die OpenGL Hilfsmittel der OpenGL Utilities (GLU) und das OpenGL Utili-
glutWireTeapot
ty Toolkit (GLUT) benutzt. Zum Zeichnen des Teekannen-Beispiels wird der
display
von der GLUT bereitgestellte Befehl benutzt. Dies geschieht
in der Methode .
Benutzte Dateien:
\src\org\ninjoworkstation\fwk\client\gof\impl\
CanvasImplJOGL.java
Abbildung 5.2: Teekanne
45
5.3 Navigation in 3D
Um in der 3D-Umgebung navigieren zu können, müssen die Maus-Events
an einen Trackball durchgereicht werden, um die zweidimensionale Einga-
mou-
be der Maus in eine dreidimensionale Änderung der Szene umzusetzen. Die
seDragged
Trackballfunktionalität sitzt hier im Canvas und zwar in der Methode
der Klasse CanvasImplJOGL. Damit die Maus-Events dorthin ge-
langen, werden sie vom Maus-Adapter des Layercontainers abgefangen. Der
Maus-Adapter reagiert auf die Maus-Events, indem er die Viewerparameter
der Szene setzt. Die Szene wird dann vom Canvas gerendert, wodurch die
neuen Viewerparameter umgesetzt werden. Der Layercontainer verwaltet die
Layercontainer-
verschiedenen Layer eines Hauptfensters. In der Klasse
ViewImpl wird dem Layercontainer der LayerContainerMouseAdapter zu-
gewiesen. Im LayerContainerMouseAdapter werden nun, wenn der Canvas
setViewerParame-
ters3D
3D-fähig ist, die Viewerparameter gesetzt. Die Methode
setzt die Einstellungen in der Szene, also in der Klasse SceneImpl. Die
Szene holt sich beim Neuzeichnen die aktuellen Positionen der 3D-Objekte
von den einzelnen Layern, während der Canvas die Szene zeichnet. In Abbil-
dung 5.3 wird die Übergabe der Mausinformationen an die dreidimensionale
Ausgabe in einer Übersicht dargestellt.
Benutzte Dateien:
\src\org\ninjoworkstation\client\appl\lc\
LayercontainerViewImpl.java
\scene\LayercontainerMouseAdapter.java
CanvasImplJOGL.java
SceneImpl.java
5.3.1 Translation und Rotation

Beim Verschieben und Rotieren von Objekten muss darauf geachtet werden,
dass die entsprechenden Matrizenmultiplikationen in der richtigen Reihenfol-
ge ausgeführt werden, da die Matrizenmultiplikation nicht kommutativ ist.
Translation Bei der Translation wird zuerst die Szene geladen, dann die
glLoadIdentity
aktuelle Matrix auf die Einheitsmatrix gesetzt. Dies geschieht mit der Metho-
glLoadMatrixf(mPos-
de . Dann wird die Matrix geladen, in der alle vorherigen Trans-
ObjTrans)
formationen gespeichert sind. Hierzu wird die Methode
mit der Matrix, in der die aktuellen Translationsinformationen
46
5.3. NAVIGATION IN 3D
Abbildung 5.3: Maus Navigation
gespeichert sind, aufgerufen. Nun folgt durch die Methode glTranslatef(x,y,z)

die aktuelle Verschiebung, die auf die geladene Matrix angewandt wird. An-
schlieÿend muss die neue Matrix gespeichert werden.
Rotation Bei der Rotation ist ein zusätzlicher Schritt zu beachten. Zu-
nächst wird wieder die Szene geladen, die Einheitsmatrix gesetzt und die
vorherigen Transformationen werden ausgeführt. Nun wird zuerst die Szene
in den Mittelpunkt verschoben, dann rotiert und zurück an den Ausgangs-
punkt bewegt und gespeichert. Das ist notwendig, da die Objekte nur um den
Nullpunkt des Koordinatensystems gedreht werden können. Dies verdeutlicht
das Beispiel in Abbildung 5.4 und Abbildung 5.5. Jede neue Transformati-
on wird auf die aktuelle Transformationsmatrix multipliziert, so dass immer
die Summe aller Transformationen mit einer Matrix auf eine Einheitsmatrix
aufmultipliziert wird.
47
Abbildung 5.4: Rotation ohne Verschiebung
Abbildung 5.5: Rotation mit Verschiebung
Benutzte Dateien:
CanvasImplJOGL.java
Codeausschnitt: CanvasImplJOGL
void doRotateObj ( GL currentGL ,

int which , float degree ,
float axisX , float axisY , float axisZ ){
...
glTranslatef ( tx , ty , 0f );
glRotatef ( degree , axisX , axisY , axisZ );
glTranslatef ( -tx , -ty , 0 f );
glMultMatrixf ( mPosObjRot );
glGetFloatv ( GL . GL_MODELVIEW_MATRIX , mPosObjRot );

...
}
48
5.3. NAVIGATION IN 3D
5.3.2 Navigieren mit Tastenkombinationen

Zur genaueren Navigation stehen dem Benutzer eine Reihe von Tastenkom-
binationen zur Verfügung, die die Mausnavigation ergänzen. Die möglichen
Tastenkombinationen weichen vom Fachkonzept ab, da eine Rotation der Sze-
ne nur mit Hilfe der Maus möglich sein sollte (vergleiche Abschnitt 4.4.6).
Durch das Drücken einer Funktionstaste in Kombination mit der linken
Maustaste kann man nun den Blickwinkel exakt wählen, wenn man die Szene
nur um eine Achse rotiert. Durch das Halten der Shift-Taste beim Zoomen
oder Verschieben wird die Schrittweite des Zooms oder der Verschiebung hal-
biert. Damit kann die Aktion sehr genau gesteuert werden. In der folgenden
Tabelle werden die Funktionen der Tastenkombinationen aufgeführt.
linke Maustaste und Funktionstaste
Alt = nur in X-Richtung rotieren

Shift = nur in Y-Richtung rotieren
Strg = nur in Z-Richtung rotieren
rechte Maustaste und Funktionstaste
Shift = Translation halbieren

mittlere Maustaste und Funktionstaste
Shift = Zoomfaktor halbieren
Benutzte Dateien:
CanvasImplJOGL.java
5.3.3 Zurücksetzen der Navigation

Nachdem der Nutzer die dreidimensionale Szene so rotiert, verschoben, ver-
gröÿert oder verkleinert hat, dass er den gewünschten Blickwinkel auf sie
hat, entsteht nun die Anforderung, die Szene wieder in die Ausgangsposition
zurück zu setzen. Für diese Funktionalität wurde ein Button zu den vorhan-
doReset
denen Navigationsbuttons des Hauptfensters hinzugefügt. Durch den Button
wird ein neues Maus-Event ausgelöst. Durch dieses Event wird ein
neuer Viewerparameter gesetzt, der beim Rendern der Szene abgefragt wird.
setOriginalPerspective
Hier wird dann die Matrix, in der die Transformation steht, auf die Ein-
mPosObjRot
heitsmatrix gesetzt. In der Methode wird die Matrix
, in der die Rotation steht, auf die Einheitsmatrix gesetzt. Dann
wird diese Matrix, die nun eine Einheitsmatrix ist, in den Matrizenspeicher
für die aktuelle Transformationsmatrix geschrieben.
49
Benutzte Dateien:
\src\org\ninjoworkstation\client\appl\lc\
scene\LayercontainerMouseAdapter.java
LayercontainerViewImpl.java
RenderContextImplJOGL.java
ViewerParametersImpl.java
Codeausschnitt: RenderContextImplJOGL
public void renderScene ( SceneImpl scene ) {

gl . glLoadIdentity ();
...
if ( reset ) {
setOriginalPerspective ();
gl . glLoadMatrixf ( mPosObjRot );
}
...
}
5.4 Beleuchtung
Um dreidimensionale Flächen darstellen zu können, muss eine Beleuchtung
der dreidimensionalen Szene erfolgen. Erst durch die Beleuchtung kommt
es zu Licht- und Schatteneekten, wodurch die Dreidimensionalität sichtbar
wird. Da sich bei einer Blickwinkeländerung sowohl die Farbe durch eine neue
Beleuchtung als auch die Reihenfolge der Objekte im Bezug zur Kamera än-
dern kann, ist zunächst ein Löschen der jeweiligen Puer-Bits notwendig. Um
nun eine Lichtquelle zu erstellen, sind zuerst der ambiente, der diuse und
der speculare Anteil zu denieren. Der ambiente Anteil beschreibt den Licht-
anteil, der so oft von Oberächen reektiert wurde, dass keine Richtung mehr
zugeordnet werden kann. Der diuse Anteil beschreibt den indirekten Anteil,
der zwar zerstreut ist, allerdings noch einer Richtung zuzuordnen ist. Der
speculare Anteil beschreibt die direkte Reexion und ist für die Glanzlichter
zuständig. Die verschiedenen Anteile werden in der RGBA-Form angegeben.
Das bedeutet, dass die drei Grundfarben und ein Transparenzparameter mit-
gegeben werden. Die Intensität ergibt sich durch die Farbe. Ein helles weiÿes
Licht hat die Werte 1, 1, 1, 1, während ein mittleres, eher graues Licht 0.5,
0.5, 0.5, 1 hat. Wenn der Anteil nicht in der Szene auftauchen soll, werden
die Farbwerte auf schwarz, also auf 0 gesetzt. Natürlich braucht auch jede
50
5.4. BELEUCHTUNG
Lichtquelle eine Position. OpenGL begrenzt standardmäÿig die Anzahl der

Lichtquellen auf 8. Im folgenden Beispiel wird nur eine Lichtquelle benutzt.
Abbildung 5.6: Beleuchtung
Benutzte Dateien:
CanvasImplJOGL.java
Codeausschnitt: CanvasImplJOGL
public void display ( GLDrawable drawable ) {

...
gl . glClear ( GL . GL_COLOR_BUFFER_BIT |
gl . GL_DEPTH_BUFFER_BIT );
...
float light_ambient [] = {0.0 f , 0.0 f , 0.0 f , 1.0 f };
float light_diffuse [] = {1.0 f , 1.0 f , 1.0 f , 1.0 f };
float light_specular [] = {1.0 f , 1.0 f , 1.0 f , 1.0 f };
float light_position [] = {1.0 f , 1.0 f , 1.0 f , 0.0 f };
gl . glLightfv ( gl . GL_LIGHT0 , gl . GL_AMBIENT ,
light_ambient );
gl . glLightfv ( gl . GL_LIGHT0 , gl . GL_DIFFUSE ,
light_diffuse );
gl . glLightfv ( gl . GL_LIGHT0 , gl . GL_SPECULAR ,
light_specular );
gl . glLightfv ( gl . GL_LIGHT0 , gl . GL_POSITION ,
light_position );
gl . glEnable ( gl . GL_LIGHT0 );
51
gl . glEnable ( gl . GL_LIGHTING );
...
}
5.5 Datenreduzierung
Unter Datenreduzierung (Subsampling) versteht man die Darstellung der Da-
ten in einer geringeren Auösung. Zur Visualisierung von Wetterdaten wird
in dieser Applikation standardmäÿig als Vorhersagemodell das lokale Modell
Europa (LME) benutzt, welches in Abschnitt 4.2.1 beschrieben wird. Da beim
LME ein Gitter mit 665 x 667 x 36 Punkten benutzt wird, ist eine Datenredu-
zierung nötig, um ein performanteres Arbeiten zu ermöglichen. In diesem Fall
werden nur die X- und die Y-Werte mit einem Subsampling bearbeitet, da
bei den 36 Höhenächen kein Subsampling notwendig ist. Die Datenreduzie-
rung geschieht in der Klasse GridThreeDExtension, da hier der Datenwürfel
geladen wird. Um das Subsampling auch noch ändern zu können, wenn die
Anwendung läuft, wird immer der komplette Datenwürfel geladen, auch wenn
das mehr Zeit kostet, als wenn man nur die Daten in der niedrigeren Auö-
sung laden würde. Sowohl das Daten- als auch das Koordinatengitter werden
ausgedünnt. Beide Gitter werden dann an den jeweiligen Visualisierungsal-
gorithmus gegeben. Hier ndet die Zuordnung der Daten zu den Koordinaten
statt. Der aktuelle Subsamplingfaktor wird aus der Konguration ausgelesen
und lässt sich über den Menüpunkt Subsampling ändern. Das Ausdünnen
der Gitter geschieht in jeweils drei ineinander geschachtelten for-Schleifen, in
denen je eine Dimension mit Sprungweite des Subsamplefaktors durchlaufen
wird.
Abbildung 5.7: links - ohne Subsampling, rechts - mit Subsampling
52
5.6. UNTERSCHEIDUNG VON 2D- UND 3D-LAYERN
Benutzte Dateien:
GridThreeDExtension.java
5.6 Unterscheidung von 2D- und 3D-Layern

Da der JOGL-Canvas sowohl zwei- als auch dreidimensionale Layer darstellen
kann, muss unterschieden werden, ob der Layer die Daten in 2D oder 3D
darstellen soll. Um dies zu erreichen, wird in der Klasse Layercontainer-
SceneDescription der aktuelle Canvas-Typ abgefragt. Wenn der Canvas
createScenegraph3D
ein JOGL-Canvas ist, wird die dreidimensionale Darstellung aktiviert, indem
im Layer die Methode aufgerufen wird. Diese Methode
existiert nur, wenn der Layer dreidimensional darstellbar ist. Falls dies nicht
zutrit, wird die zweidimensionale Darstellung gezeichnet. In dieser Arbeit
sind zwei Layer 3D-fähig: der NWP-Layer, der die Gitterdaten darstellt und
der Georasterlayer, der die Erdoberäche zeigt.
Benutzte Dateien:
\src\org\ninjoworkstation\client\appl\lc\scene\
LayercontainerSceneDescription.java
\src\org\ninjoworkstation\client\grid\pac\layer\
BaseGridView.java
Codeausschnitt: LayercontainerSceneDescription
public void updateSceneContent () throws NjException {

...
if ( cfg != null && cfg . hasCanvasType ()) canvasType =
cfg . getCanvasType ();
...
if ( canvasType == 3){ sceneCmd =
new CollectSceneContentCommand ( ctrl , Dimension_3D );
}
5.7 Übergabe von 2D an 3D

Wenn im normalen, zweidimensionalen Betrieb von NinJo der 3D-Button be-
tätigt wird, möchte der User die gleichen Daten, die er betrachtet hat, auch in
53
der dreidimensionalen Darstellung sehen. Aus diesem Grund muss eine Über-
gabe der Daten zwischen zwei Hauptfenstern erfolgen. Dies ist im Design von
NinJo nicht vorgesehen. Dort ist eine strikte Trennung der einzelnen Layer
gefordert. Eine direkte Kommunikation der Layer untereinander, ohne Ein-
beziehung des Frameworks ist nicht erwünscht. In dem Fall besteht allerdings
genau diese Anforderung. Deshalb wird nun der aktuelle Gridrequest, in dem
die Anfrage nach Modell, Element, Leveltyp, Modelllauf und Vorhersagezeit-
punkt steht, in ein Singleton geschrieben, welches in der 3D-Verarbeitung
verfügbar ist. Dies wird von der Klasse Grid2Dto3D erzeugt. In der Klasse
BaseGridModel wird in der Methode setRequest
renderRequest
das Singleton erzeugt. In
der Klasse BaseGridView in der Methode wird es dann wie-
der ausgelesen. Damit ist die Möglichkeit gegeben, die letzte Anfrage an das
Gridlayer sowohl in der zweidimensionalen als auch in der dreidimensionalen
Ansicht zu bekommen. Leider berücksichtigt diese Methode nicht die gleich-
zeitige Verwendung von mehreren Gridlayern. Die Implementierung dieser
Funktionalität ist im Rahmen der Diplomarbeit wegen des Abstimmungs-
aufwands nicht vorgesehen und muss im Rahmen der Weiterentwicklung in
Absprache mit den Designverantwortlichen implementiert werden.
Benutzte Dateien:
\src\org\ninjoworkstation\client\grid\pac\layer\
BaseGridModel.java
BaseGridView.java
\src\org\ninjoworkstation\client\grid\grid\pac\layer\
Grid2Dto3D.java
5.8 3D-Werkzeugleiste
Um die möglichen Funktionen übersichtlich darzustellen, wurden aus der im
Fachkonzept vorgestellten Werkzeugleiste für die vorliegende Version der Ap-
plikation nur wenige Punkte ausgewählt. Wenn die Anwendung im 3D-Modus
ist, werden alle Punkte des zweidimensionalen Gridlayers ausgeblendet und
nur die 3D-Funktionen eingeblendet. Hier können nun die Datenauswahl auf-
gerufen, die Visualisierungen gewechselt oder die Einstellungen der Visuali-
sierungen geändert werden.
54
5.9. 3D-ISOFLÄCHEN
Datenauswahl
Visualisierung mit Tiny Cubes
Einstellungen für Tiny Cubes
Visualisierung mit 3D-Isoächen
Einstellungen für 3D-Isoächen
Abbildung 5.8: 3D-Werkzeugleiste
Benutzte Dateien:
GridToolBar.java
5.9 3D-Isoächen
Die Darstellung von Daten als dreidimensionale Isoächen geschieht in der
Klasse Isosurface, die aus einem früheren Prototypen übernommen wur-
de. Sie benutzt einen VisAD-Algorithmus, der zur Extraktion der Flächen
Marching Cubes verwendet, wie in Abschnitt 2.2.3 vorgestellt. Da der Algo-
rithmus sehr ezient ist, nimmt er keine Rücksicht darauf, ob beim Zusam-
mensetzen der Isoächen aus Dreiecksächen alle Oberächennormalen in die
GridThreeD-
getElementAppearance set-
gleiche Richtung zeigen. Aus diesem Grund wird in der Klasse
Extension
InconsistentFaces(true)
in der Methode das Polygonattribut
gesetzt, welches dafür sorgt, dass die Oberächen-
normalen korrigiert werden.
Benutzte Dateien:
\src\org\ninjoworkstation\fwk\client\vislib\threed\
Isosurface.java
55
Abbildung 5.9: Isoächen
5.9.1 Neues Polygon mit neuer Appearance

Um nach dem Berechnen der Isoächen und dem Setzen deren Appearan-
ce anderen Polygonen eine andere Appearance zuzuweisen, muss nach dem
setInconsistentFaces(true)
Rendern eines Polygons die Farbe und das Material wieder zurückgesetzt
werden. Die Methode hat bei Polygonen, die kei-
ne unterschiedlichen Flächennormalen haben, zur Folge, dass Vorder- und
Rückseiten vertauscht werden. Da die Rückseiten durch ein Backfacecul-
ling nicht dargestellt werden, sind nach dem Vertauschen nur die ehema-
ligen Rückseiten sichtbar. Standardmäÿig ist die Vorderseite eines Polygons
dadurch deniert, dass die Punkte des Polygons gegen den Uhrzeigersinn
durchlaufen werden. Durch den Isoächenalgorithmus kann die Vordersei-
gl.glFrontFace(GL.GL_CCW)
te im Uhrzeigersinn gestellt sein. Aus diesem Grund muss nach dem Ren-
dern mit die Vorderseite gegen den Uhrzeiger-
sinn (CounterClockWise) zurückgestellt werden. Damit dem neuen Polygon
gl.glDisable(GL.GL_COLOR_-
auch neue Farben und neue Materialien zugewiesen werden können, müssen
diese Eigenschaften nach dem Rendern mit
56
5.10. TINY CUBES
MATERIAL) zurückgesetzt werden.
Benutzte Dateien:
RenderContextImplJOGL.java
5.9.2 Schwellenwerteingabe
Um eine dreidimensionale Isoäche zeichnen zu können, braucht man einen
setDefaultThreshold
Schwellenwert, der die Isoäche bestimmt. Der Startschwellenwert wird für
alle Elemente durch die Methode gesetzt. Hier wird je-
dem Element automatisch ein geeigneter Startwert zugeordnet. Der Startwert
kann nachträglich vom Benutzer durch einen Slider geändert werden, den man
durch einen Button der Layertoolbar des 3D-Gridlayers önen kann. Durch
den Slider wird ein neuer Schwellenwert gesetzt und ein Neuzeichnen ange-
stoÿen. Um den Schwellenwert vom Slider an die Isoächen zu übergeben,
muss in der Klasse GridToolBar der Slider erzeugt werden. Der Slider setzt
in der Klasse ThresholdGUI den Schwellenwert im View mit der Methode
setThreshold. In der Klasse BaseGridView wird dann der Schwellenwert für
die Klasse GridThreeDExtension gesetzt. Dies wird in der Abbildung 5.10
verdeutlicht.
Benutzte Dateien:
GridToolBar.java
\gui\ThresholdGUI.java
5.10 Tiny Cubes

Eine andere Möglichkeit, um Volumendaten zu visualisieren, ist die Tiny
Cubes Methode. Wie schon im Grundlagenteil vorgestellt, wird bei dieser
Methode für jeden Datenpunkt ein Primitiv, meistens ein Würfel, gezeich-
net. Dadurch, dass die Primitive einen Abstand zueinander haben, kann man
auch die Werte im Inneren des Volumens sehen. In dieser Arbeit wurden als
Primitive Punkte gewählt, da die Gitter, die visualisiert werden, sehr dicht
sind. Es wird jedoch nicht für jeden Datenpunkt ein Farbwert ermittelt, da
57
Abbildung 5.10: Schwellenwert setzen
dies zu unübersichtlich würde. Die Datenpunkte werden durch zwei Schwel-

lenwerte in drei Bereiche eingeteilt. Für jeden Bereich wird der Abstand der
Punkte, die Farbe und die Transparenz festgelegt. Für jedes Element wird
eine Starteinstellung der Werte gewählt, die eine sinnvolle Visualisierung der
Daten erzeugt.
Benutzte Dateien:
TinyCubes.java
5.10.1 Werte-Eingabe
Es gibt für den Nutzer auch die Möglichkeit, die voreingestellten Werte für
die Tiny Cubes Visualisierung zu ändern. Es können die beiden Schwellenwer-
te geändert werden. Für jeden Bereich kann die Dichte und die Transparenz
58
5.10. TINY CUBES
Abbildung 5.11: Tiny Cubes
der Punkte eingestellt werden. Die Dichte beschreibt, mit welcher Schritt-
weite durch das Datengitter gegangen wird, das heiÿt wie viele Gitterpunkte
übersprungen werden. Bei der Transparenz wird ein Wert zwischen 0 (un-
sichtbar) und 1 (undurchsichtig) gewählt. Die Farbe lässt sich nicht ändern,
da zu viele Eingabemöglichkeiten ein Eingabefeld unübersichtlich machen.
Die Farbe wird man später durch die Änderung einer Kongurationsdatei
editieren können.
Benutzte Dateien:
TinyCubes.java
\gui\ChangeValuePanel.java
59
5.11 Höhenprol für Georaster

Im Georasterlayer wird die Erdoberäche durch Satellitenbilder dargestellt.
Mit der Farbtabelle GTOPO30 werden die verschiedenen Höhen in bestimm-
ten Farben dargestellt. In der Klasse GeoRasterThreeDExtension wird dann
dem zweidimensionalen Georasterbild für jedes Pixel je nach Farbe ein Hö-
henwert zugewiesen. So entsteht das dreidimensionale Georasterbild. Es müs-
sen auch in der Klasse RasterViewImpl Anpassungen durchgeführt werden.
createScenegraph3D
Da der Layer auch dreidimensionale Daten darstellt, muss hier die Methode
implementiert werden. Man könnte eine höhere Auö-
sung erreichen, indem man das Rasterbild aus der Klasse RasterViewImpl
mit Hilfe von Java Advanced Imaging (JAI) einmalig heraus schreibt und in
der Klasse GeoRasterThreeDExtension mit JAI wieder einliest. Durch die
Performancenachteile, die diese Methode mit sich bringt, wird es in der vor-
liegenden Arbeit nicht implementiert. Die Auösung von 958 x 556 x 258, die
vom Georasterlayer geliefert wird, reicht jedoch für diesen Rahmen aus. Da-
ninjo.client.raster.geo.pac.layer.model
mit beim Starten der 3D-Anwendung die richtige Farbtabelle gewählt wird,
wurde in der default-cong GTOPO30
eingestellt, so dass diese Farbtabelle standardmäÿig beim Starten benutzt
wird.
Benutzte Dateien:
\src\org\ninjoworkstation\client\raster\pac\layer\
GeoRasterThreeDExtension.java
RasterViewImpl.java
\installation\common\client\remote_config\cfg\system\default\
ninjo.client.raster.geo.pac.layer.model\default.xml
5.12 Mapping der Visualisierung

Für den Fall, dass die 3D-Applikation aus dem zweidimensionalen NinJo
setDefaultEle-
mit einem Element aufgerufen wird, muss dem Element eine Visualisierung
mentVisualisation
zugewiesen werden. Diese Aufgabe übernimmt die Methode
der Klasse GridThreeDExtension, die entscheidet, ob das
Element mit einer Isoäche oder mit Hilfe von Tiny Cubes visualisiert wird.
Wenn weitere Visualisierungen hinzukommen, müssen diese in der Methode
berücksichtigt werden. Hier werden die Elemente betrachtet, die im Grid-
layer auf den Modellächen vorliegen. Isoächen sind für Elemente inter-
essant, bei denen einzelne Werte eine wichtige Bedeutung haben, wie zum
60
5.12. MAPPING DER VISUALISIERUNG
Abbildung 5.12: Georaster
Beispiel 0 Grad bei der Temperatur. Tiny Cubes werden dann bevorzugt,
wenn man Wertebereiche betrachten möchte. Die Zuordnung der Elemente
zu Visualisierungen sieht man in der folgenden Tabelle. Natürlich kann die
Visualisierung vom Nutzer nachträglich geändert werden.
Element Visualisierung
Temperatur → Isoächen
Feuchtigkeit → Tiny Cubes
Bedeckungsgrad (Wolken) → Isoächen
U-Wind Komponente (West/Ost) → Tiny Cubes
V-Wind Komponente (Süd/Nord) → Tiny Cubes
Luftdruck → Isoächen
Als Visualisierung für die Temperatur werden Isoächen gewählt, da die

◦
Temperatur 0 C ein sehr markanter Wert in der Meteorologie ist. Bei der
Feuchtigkeit ist der Bereich mit sehr hoher Luftfeuchtigkeit interessant, so
61
wird hier die Visualisierung mit TinyCubes gewählt, wobei alle Werte über 90
% hervorgehoben werden. Für den Bedeckungsgrad ist zwar auch ein Bereich
interessant, da hier die höheren innerhalb der niedrigeren Werte liegen, wurde
eine Isoächendarstellung gewählt. Mit dem Schwellenwert von 80 % kann
gut die Bewölkung erkannt werden. Die beiden Windkomponenten werden
durch Tiny Cubes dargestellt, da hier die Unterscheidung zwischen positi-
ven, negativen und Werten um 0 wichtig ist. Die verschiedenen Richtungen
repräsentieren den Gesamtwindvektor. Der Luftdruck wird als Isoäche dar-
gestellt, um eine bessere Orientierung im Druckwürfel zu ermöglichen. In den
folgenden Abschnitten wird auf die Schwellenwerte der einzelnen Visualisie-
rungen eingegangen, wo, der Vollständigkeit halber, für jede Visualisierung
alle Elemente betrachtet werden.
Benutzte Dateien:
5.12.1 Mapping auf Isoächen

Wenn zur Visualisierung Isoächen benutzt werden, muss zum Erzeugen der
setDefaultThreshold
Isoäche ein Schwellenwert mitgegeben werden. Für jedes Element wird ein
eigener Schwellenwert mit der Methode festgelegt. Der
Benutzer kann den Schwellenwert mit Hilfe eines Sliders nachträglich verän-
dern.
Element Schwellenwert
Temperatur → 0
Feuchtigkeit → 90
Bedeckungsgrad (Wolken) → 80
U-Wind Komponente (West/Ost) → 0
V-Wind Komponente (Süd/Nord) → 0
Luftdruck → 850
Benutzte Dateien:
62
5.12. MAPPING DER VISUALISIERUNG
5.12.2 Mapping auf Tiny Cubes

Bei Verwendung der Visualisierungsmethode Tiny Cubes müssen für jedes
Element bestimmte Werte gesetzt werden. Es werden eine obere, eine un-
setDefaultTinyCubesSet-
tere Schwelle und für die drei Bereiche jeweils Dichte und Transparenz pro
ting
Element deniert. Dies geschieht in der Methode
. Der Übersichtlichkeit halber zeigt die Tabelle nur die untere und obere
Schwelle und lässt die Dichten und Transparenzwerte auÿen vor.
Element untere, obere Schwelle
Temperatur → -5, +5
Feuchtigkeit → 90, 100
Bedeckungsgrad (Wolken) → 60, 80
U-Wind Komponente (West/Ost) → -2, +2
V-Wind Komponente (Süd/Nord) → -2, +2
Luftdruck → 500, 800
Benutzte Dateien:
63
64
Kapitel 6
Nutzertests
Dem folgenden Kapitel liegen die Quellen [Chl06], [Nie93] und [QE07] zu-
grunde.
6.1 Nutzergruppen
Die Nutzergruppe der 3D-Applikation ist international und sehr homogen.
Alle Anwender arbeiten in den Vorhersagezentralen der Wetterdienste ver-
schiedener Nationen. Sie kennen NinJo und verwenden das System zum Teil
operativ. Die 3D-Applikation stellt für sie eine Neuerung dar. Die eigentliche
Arbeitsumgebung ist bekannt. Auÿer den Mitarbeitern der Vorhersagezen-
tralen werden ebenso Entwickler von NinJo in den Test einbezogen, um eine
breitere Testbasis zu erhalten. Sowohl Meteorologen als auch Entwickler sind
als Experten im Umgang mit dem System zu sehen. Es werden bewusst keine
Anfänger in den Test einbezogen, da diese nicht mit dem System arbeiten
werden.
6.2 Methoden
Die beiden Methoden für den Nutzertest, die in diesem Fall in Frage kommen,
sind der Fragebogen und das Experteninterview. Im Folgenden werden die
Vorteile und Nachteile der beiden Methoden erläutert.
6.2.1 Fragebogen
Ein Fragebogen hat den Vorteil, dass eine gröÿere Menge an Testpersonen
befragt werden kann, ohne dass ein Testleiter bei jeder Testperson anwesend
sein muss. Damit ist auch die Anonymität der Testpersonen gewahrt. Wenn
65
KAPITEL 6. NUTZERTESTS
der Fragebogen entsprechend gestaltet ist, kann er auch maschinell ausgewer-

tet werden. Dadurch, dass beim Test kein Testleiter anwesend ist, ergeben
sich auch einige Nachteile. So muss mit einem geringen Rücklauf der Fra-
gebögen gerechnet werden. Es können auch Fragebögen unbrauchbar sein,
wenn der Nutzer die Aufgaben falsch verstanden hat. Bei einer groÿen Men-
ge an Testpersonen ist demnach der Fragebogen die Methode der Wahl. Bei
einer kleinen Gruppe von Testnutzern kann allerdings der Informationsver-
lust zu groÿ sein und so die Auswertung erschweren. Aus diesem Grund ist
das Experteninterview das Mittel der Wahl.
6.2.2 Experteninterview
Durch den persönlichen Kontakt mit jedem Nutzer, der an dem Test teil-
nimmt, ist sichergestellt, dass die maximale Information pro Testnutzer her-
ausgefunden wird. Hier können komplexe Fragestellungen behandelt werden,
die eine zusätzliche Erklärung benötigen. Bei einer fachkundigen Nutzer-
gruppe können so leichter Anregungen für Verbesserungen des getesteten
Programmes aufgenommen werden. Durch das persönliche Gespräch muss
allerdings mit einem gröÿerem Zeitaufwand pro Test gerechnet werden, als
das bei einem Fragebogen der Fall wäre. Auÿerdem ist die Qualität der Test-
ergebnisse vom Interviewer abhängig.
6.3 Interview
Bei der Wahl der Methode bot sich aus den oben genannten Gründen für diese
Arbeit das Experteninterview an. Deswegen wird im Folgenden genauer auf
diese Methode eingegangen.
6.3.1 Planung und Durchführung

Thema Bevor ein Interview durchgeführt werden kann, muss natürlich das
Thema klar sein. Auÿerdem muss überprüft werden, ob das Experteninter-
view die geeignete Methode für das Thema des Testes ist. In dem Nutzertest
für die vorliegende Arbeit lautet das Thema Visualisierung von Wetterdaten
in 3D.
Testnutzer wählen Im nächsten Schritt werden die Nutzer für den Test
ausgewählt. Wie in Kapitel 6.1 erwähnt, werden Nutzer aus der Gruppe der
Meteorologen und aus der Gruppe der Entwickler befragt.
66
6.3. INTERVIEW
Befragungsform festlegen Für die Form der Befragung müssen der Struk-
1
turierungsgrad , die Art des Kontaktes (zum Beispiel direkt oder telefonisch),
die Zahl der Interviewer und die Zahl der Interviewten pro Test festgelegt
werden. Unter diesen Punkt fällt auch die geplante Dauer des Interviews.
Interviewleitfaden Jedes Interview braucht einen Leitfaden, der die Struk-

tur des Interviews vorgibt. Er dient als Orientierung für den Interviewer.
Anfrage und Instruktion der Nutzer Bei der Anfrage und auch bei
der Instruktion der Nutzer für den Test, muss deutlich gemacht werden, wie
wichtig die Meinung des Nutzers ist und welchem Zweck das Interview dient.
Da ein Interview nie anonym sein kann, ist es notwendig, den Nutzer darauf
hinzuweisen, dass seine Daten vertraulich behandelt werden.
Interviewmethoden Um während des Interviews so viele Informationen

wie möglich vom Testnutzer zu bekommen, wird die Methode des lauten
Denkens benutzt. Dabei wird der Nutzer gebeten, während des Interviews
seine Gedanken laut zu äuÿern. Es wird notwendig sein, den Nutzer immer
wieder an diese Interviewform zu erinnern.
Aufzeichnung und Aufbereitung Das Interview sollte entweder auf Ton-

band oder auf Video aufgenommen werden, um es später genau auswerten
zu können. Da diese Möglichkeit hier aus organisatorischen Gründen nicht
besteht, werden bei der Befragung Notizen gemacht, die direkt nach dem
Interview ergänzt werden. Um die Testergebnisse aufzubereiten, werden die
Notizen digitalisiert. Dies hilft vor allem bei der quantitativen Auswertung.
6.3.2 Auswertung
Die Auswertung der Nutzertests kann sowohl quantitativ als auch qualitativ
erfolgen.
Quantitative Auswertung Bei der quantitativen Auswertung wird die

Antwort des Nutzers auf eine Frage einer Kategorie zugeordnet. Dann kann
die Häugkeit der genannten Kategorien zur Interpretation des Ergebnisses
genutzt werden. Aus diesem Grund ist eine groÿe Anzahl von Antworten
hilfreich. Diese Art der Auswertung eignet sich mehr für geschlossene Fragen.
Bei oenen Fragen könnten viele Informationen verloren gehen.
1 Grad der Lenkung durch den Interviewer
67
Qualitative Auswertung Bei der qualitativen Auswertung können für

das protokollierte Interview verschiedene wissenschaftliche Methoden ange-
wendet werden, auf die nicht näher eingegangen wird, da hier die Selbsteva-
luation die beste Methode ist. Für diese werden die Aussagen der Testperso-
nen anhand der Testfragen vom Interviewer selbst untersucht, zusammenge-
fasst und interpretiert.
6.3.3 Interpretation
Die Interpretation der aus der Auswertung gewonnenen Informationen ge-
schieht anhand der im Vorfeld formulierten Erwartungen (vergleiche 4). Durch
Bestätigung oder Abweichung dieser Erwartungen können neue Erkenntnisse
erlangt werden.
68
6.4. TEST
6.4 Test
6.4.1 Testplan
Thema Visualisierung von Wetterdaten in 3D
Testnutzer wählen
• Meteorologen: 4
• Entwickler: 4
Befragungsform festlegen
• Strukturierungsgrad: halb strukturiert (oene und geschlossene Fragen)
• Art des Kontaktes: direkt/persönlich
• Zahl der Interviewer: 1
• Zahl der Interviewten pro Interview: 1
• Dauer: 15 bis 20 Minuten
Interviewleitfaden
• Instruktion des Nutzers
• Persönliche Daten
• Vorstellung des Programms
• Aufgaben an den Nutzer
• Fragen an den Nutzer
• Nachbesprechung
Interviewmethoden Methode des lauten Denkens
Aufzeichnung und Aufbereitung Notizen, die nach dem Interview er-

gänzt werden.
69
6.4.2 Testbogen
Persönliche Daten
• Berufsgruppe: ...
• Erfahrung mit NinJo: ...
• Erfahrung mit 3D-Anwendungen: ...
Aufgaben an den Nutzer

• Starten Sie NinJo in 2D und suchen Sie im Gridlayer ein bestimmtes
Element heraus (LME oder LMK, Modelllauf 00:00 Uhr, Temperatur,
Bedeckungsgrad, U Wind, V Wind oder Druck).
• Starten Sie die 3D-Ansicht und betrachten Sie das Ergebnis.
• Wechseln Sie zwischen den Visualisierungen, ändern Sie die Werte,

wechseln Sie das Element.
• Stellen Sie einen Screenshot einer Ihrer Meinung nach gelungenen An-
sicht her.
Fragen an den Nutzer

• Wie sinnvoll nden Sie die Anwendung auf einer Skala von 1 (schlecht)
bis 10 (sehr gut)?
• Für welchen Zweck würden Sie die Anwendung einsetzen? (Zum Bei-
spiel Präsentationen, erster Eindruck über eine Wetterlage oder Detail-
analyse)
• Was stört Sie bei der Navigation?
• Welche Funktion vermissen Sie am meisten? (Zum Beispiel mehr 3D-

fähige Layer wie Radar, mehr Einstellungsmöglichkeiten der Visualisie-
rungen wie Farbe, zusätzliche Visualisierungen wie Cross-Sections)
• Welche Anregungen haben Sie für die Anwendung?
70
6.5. AUSWERTUNG
6.4.3 Pilottest
Nach der Durchführung des Pilottestes wurde klar, dass die oenen Fra-
gen nach dem Erstellen des Screenshots den Nutzer überfordern, wenn keine
Skalierung oder Beispiele angegeben werden. Aus diesem Grund wurden alle
Fragen an den Nutzer diesen Punkt betreend überarbeitet.
6.5 Auswertung
6.5.1 Quantitative Auswertung
Während des Interviews wurden vier Fragen gestellt, die quantitativ ausge-
wertet werden konnten. Das Ergebnis der Auswertung der einzelnen Fragen
wird in der folgenden Tabelle und in den Diagrammen von Abbildung 6.1 bis
Abbildung 6.4 dargestellt.
Beruf Erfahrung mit Erfahrung mit Bewertung

3D-Anwendungen NinJo der Anwendung
Entwickler Ja 2 Jahre 8
Meteorologe Nein 6 Monate 9
Entwickler Nein 7 Jahre 7 - 8
Entwickler Ja 4 Monate 2
Meteorologe Ja 7 Jahre 5
Meteorologe Ja 7 Jahre 10
Entwickler Ja 4 Jahre 8
Meteorologe Nein 7 Jahre 7
Die Tabelle zeigt, dass die Testnutzer eine durchschnittliche Erfahrung von
4,35 Jahre mit NinJo haben und die Anwendung durchschnittlich mit 7,06
von 10 Punkten bewerten.
6.5.2 Qualitative Auswertung

Für welchen Zweck würden Sie die Anwendung einsetzen? Die
meisten Nutzer würden die Anwendung zur genaueren Betrachtung von inter-
essanten Wettersituationen benutzen. Es zeigt sich auch, dass die Anwendung
zu Präsentationszwecken genutzt würde.
Was stört Sie bei der Navigation? Hier äuÿerten die Anwender ihren
Unmut über die schwierige Navigation. Das Ruckeln, das aus Performance-
71
Abbildung 6.1: Beruf
Abbildung 6.2: Erfahrung mit 3D
gründen auftritt, ist für viele Nutzer ein Hindernis, um mit der Anwendung
ezient zu arbeiten.
Welche Funktion vermissen Sie am meisten? Hier teilt sich die Mei-
nung der Nutzer. Für die einen sind weitere Einstellungsmöglichkeiten wie
die Farben der Punkte und Flächen das Wichtigste, für andere ist es am
72
6.5. AUSWERTUNG
Abbildung 6.3: Erfahrung mit NinJo
Abbildung 6.4: Bewertung der Anwendung
Wichtigsten, möglichst viele Layer dreidimensional darstellen zu können.
Welche Anregungen haben Sie für die Anwendung? Zu diesem Punkt

wurden die unterschiedlichsten Anregungen gemacht, von denen einige wie
folgt genannt werden. Es kam der Wunsch nach einer Legende, die anzeigt,
um welche Achse man die Szene rotiert. Die Möglichkeiten, bei Isoächen
73
eine Transparenz einzustellen, nicht nur Modell- sondern auch Druckächen

anzeigen zu lassen und die Ansicht aufschneiden und sich den Schnitt be-
trachten zu können waren weitere Wünsche.
6.6 Interpretation
Durch die Auswertung der Fragebögen wird klar, dass der Benutzer die An-
wendung gern annimmt und verwendet, wenn die Navigation verbessert wird.
Zusätzliche Möglichkeiten der Einstellungen oder die Anzeige von weiteren
Layern sind gewünscht, aber eher optional. Das einfache Starten der 3D-
Anwendung und eine gute Voreinstellung ermöglichen es dem Anwender, mit
wenig Aufwand um ein brauchbares Resultat zu erreichen. Dies trägt wesent-
lich zum positiven Feedback der Nutzer bei.
74
Kapitel 7
Ausblick
Im folgenden Kapitel werden die Punkte betrachtet, die im zeitlichen Rahmen

der Diplomarbeit nicht verwirklicht werden konnten. Es handelt sich zum
einen um Funktionalitäten, die im Fachkonzept beschrieben wurden, zum
anderen um die Auswertungsergebnisse der Nutzertests.
7.1 Prioritäten
Die fünf wichtigsten Punkte, die zur produktiven Einführung der Anwendung
implementiert werden müssen, sind im Folgenden aufgezählt:
• Navigation Die Nutzertests haben gezeigt, dass die Performance der

Navigation verbessert werden muss, um ein ruckelfreies Navigieren zu
gewährleisten, da kurze Rechenpause während der Mausbewegung für
den Nutzer sehr störend sind. Dies kann unter anderem durch einen grö-
ÿeren voreingestellten Subsamplingfaktor erreicht werden oder durch
eine Erdoberächentextur mit einer geringeren Auösung.
• Legende Damit der Nutzer weiÿ, was auf dem Bildschirm dargestellt
wird, sind Legenden notwendig. NinJo stellt mit einem Legend-Frame-
work eine Methode bereit, Legenden in ein Layer zu integrieren.
• Radar Die Darstellung von Radardaten in der 3D-Anwendung ist eine

Forderung der Meteorologen. Die Daten liegen bereits dreidimensional
vor, müssen allerdings auf die Gitterkoordinaten umgerechnet werden,
da sie, wie im Fachkonzept erläutert, in Sweeps gespeichert sind. Durch
die dreidimensionale Visualisierung der Radardaten bieten sich bei der
Analyse einer Wettersituation für die Meteorologen dann neue Mög-
lichkeiten.
75
KAPITEL 7. AUSBLICK
• Cross-Section Eine weitere wichtige Visualisierung ist die Darstellung

zweidimensionaler Schnitte in die dreidimensionale Darstellung. Sowohl
horizontale als auch vertikale Cross-Sections können von NinJo bereits
dargestellt werden. Anhand der Integration in die dreidimensionale An-
sicht kann der Meteorologe Details besser analysieren.
• Konguration Für den produktiven Einsatz ist es notwendig, alle

Einstellungen der 3D-Anwendung nicht fest in den Programmcode zu
setzen, sondern mit Hilfe von Kongurationsdateien zu steuern. Diese
werden vom im NinJo verwendeten Cong-Framework verwaltet und
stellen eine nachträgliche Anpassung an Nutzerbedürfnisse sicher.
7.2 Oene Punkte

Weitere Programmfunktionen, die nicht im zeitlichen Rahmen der Arbeit
verwirklicht werden konnten, werden im Folgenden in verschiedene Bereiche
eingeteilt. Diese Punkte müssen nach der Implementierung der Prioritäten
und vor einem operationellen Betrieb umgesetzt werden.
7.2.1 Visualisierungen
Vektordarstellung Die im Fachkonzept vorgestellte Vektordarstellung zeigt
die Windvektoren, die sich aus den U- und V-Windkomponenten zusammen-
setzen.
Schatten Da OpenGL keine Wurfschatten rendert, müssen die Schatten

bei der Berechnung der Isoächen mitberechnet und auf die Oberäche ge-
rendert werden.
7.2.2 Elemente
Druckächen Es sollen in Zukunft nicht nur die Elemente der Modellä-
chen, die in dieser Arbeit in Abschnitt 5.12 behandelt wurden, dargestellt
werden, sondern auch alle Element der Druckächen die im Fachkonzept un-
ter 4.3.2 erwähnt sind.
7.2.3 Konguration
I18N In einer produktiven Version müssen alle Kongurationen und Texte,
die in der Benutzeroberäche zu sehen sind, mit Hilfe des I18N-Frameworks
76
7.3. OPTIONALE PUNKTE
internationalisiert werden, damit alle Texte in allen Sprachen verfügbar sind.

Dies ist in einem internationalen Projekt, wie NinJo, unverzichtbar.
7.3 Optionale Punkte

Hier werden Funktionen beschrieben, die für einen operationellen Betrieb
nicht notwendig sind und somit in dieser Arbeit nicht implementiert wurden.
7.3.1 GUI-Elemente
Schnitt Das Bewegen einer Ebene durch den dreidimensionalen Raum, so
dass alles zwischen dieser Ebene und der Kamera transparent gezeichnet
wird, ist eine im Fachkonzept beschriebene Funktion, die in einer späteren
NinJo-Version verwirklicht wird.
7.4 Operationeller Betrieb

Ein operationeller Einsatz der Anwendung ist für die NinJo-Version 1.4 ge-
plant. Momentan wird NinJo in der Version ist. 1.2.8 verwendet, die Mi-
gration auf 1.3 ist kurz vor dem Abschluss. Der Einsatz von NinJo 1.4 für
2009 geplant. Bis zu diesem Zeitpunkt müssen die Prioritäten und die oenen
Punkte umgesetzt werden.
77
KAPITEL 7. AUSBLICK
78
Kapitel 8
Zusammenfassung
Die Aufgabe dieser Arbeit war es, eine in die NinJo-Workstation eingebet-
tete Applikation zu entwickeln, die mit nur einem Mausklick eine zweidi-
mensionale Darstellung von meteorologischen Daten in eine dreidimensiona-
le Darstellung. NinJo ist eine meteorologische Workstation, die komplett in
Java geschrieben ist und es Meteorologen ermöglicht, Wetterdaten zu ana-
lysieren (vergleiche Kapitel 3). Im Rahmen eines Fachkonzeptes wurden die
Funktionen der Anwendung beschrieben (vergleiche Kapitel 4). Bei der Um-
setzung (vergleiche Kapitel 5) mussten erst die Möglichkeiten, welche die
NinJo-Workstation bereitstellt, so eingesetzt werden, dass Daten dreidimen-
sional dargestellt werden konnten. Anschlieÿend wurden zwei verschiedene
Visualisierungen implementiert, um eine automatische Auswahl einer Visua-
lisierung zu ermöglichen. Dadurch wurde die Voraussetzung geschaen, ein
Element, wie zum Beispiel die Temperatur oder die Bewölkung, als Isoäche
darzustellen oder die Volumenvisualisierung Tiny Cubes zu wählen. Für die
möglichen Visualisierungen waren verschiedene Parameter nötig, die für je-
des Element mit einer anderen Voreinstellung belegt werden mussten. Sowohl
die Parameter als auch die Visualisierung lassen sich im laufenden Betrieb
der Anwendung vom Benutzer ändern. Ebenso ist es möglich, mehrere Ele-
mente gleichzeitig anzeigen zu lassen oder ein Element in mehreren Visua-
lisierungen simultan zu betrachten. Die Zahl der auf einmal zu betrachten-
den Elemente ist nur vom Arbeitsspeicher und der Rechenleistung des PCs
beschränkt, auf dem der NinJo-Client läuft. Schon mit dem jetzigen Pro-
totypen, der im Rahmen der Arbeit entstand, ist es für den Meteorologen
möglich, bestimmte Wetterphänomene zu analysieren. So lässt sich beobach-
ten, wie der Temperaturverlauf durch die Alpen beeinusst wird (Abbildung
◦
8.1 bei -15 C) oder in welchem Bereich der Wolken eine so niedrige Tem-
peratur herrscht, dass Eisregen möglich ist (Abbildung 8.2, Grün bedeutet
◦
-5 bis -15 C). Dies ist vor allem für die Flugwetterberater sehr interessant.
79
KAPITEL 8. ZUSAMMENFASSUNG
Dadurch, dass für die Meteorologen diese Informationen jetzt durch einen
Mausklick einfach zugänglich sind, werden sie diese und somit auch die neue
Anwendung gern nutzen. Das ergaben auch die durchgeführten Nutzertests
(vergleiche Kapitel 6). Dadurch, dass die Visualisierungen optisch eindrucks-
voll und für eine weitergehende Analyse ergiebig sind, steigt natürlich auch
die Akzeptanz der Nutzer. Die Einbindung in das vom Wetterdienst genutzte
Dateimanagementsystem ermöglicht eine Weiterentwicklung der Anwendung
ohne zusätzlichen administrativen Aufwand. Nach Abschluss der Arbeit und
der Umsetzung einiger der im Ausblick genannten Funktionen wird die 3D-
Applikation in das produktive NinJo-System aufgenommen und somit im
operationellen Betrieb von Meteorologen international genutzt werden.
80
Abbildung 8.1: Screenshot Temperatur über den Alpen
Abbildung 8.2: Screenshot Wolkenvereisung
81
KAPITEL 8. ZUSAMMENFASSUNG
82
Anhang
Im Anhang bendet sich
• das Abbildungsverzeichnis,
• das Literaturverzeichnis,
• die Fragebögen und
• das Inhaltsverzeichnis der CD
83
84
Abbildungsverzeichnis
2.1 Quadermethode . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Transparente Quadermethode . . . . . . . . . . . . . . . . . . 9
2.3 Schichtenmethode . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4 Varianten der Schichtenmethode . . . . . . . . . . . . . . . . . 10
2.5 Contouring and Connecting . . . . . . . . . . . . . . . . . . . 11
2.6 Fallunterscheidungen beim Marching Cube . . . . . . . . . . . 12
2.7 Volume Rendering . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1 NinJo Übersicht [EuM07] . . . . . . . . . . . . . . . . . . . . . 15

3.2 NinJo Screenshot . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3 Layer [Leh03] . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.4 Cross-Section . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.5 NinJo Architektur [Leh03] . . . . . . . . . . . . . . . . . . . . 18
3.6 NinJo-Client [Leh03] . . . . . . . . . . . . . . . . . . . . . . . 19
4.1 GME [Wet07a] . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.2 Radarprinzip [Wet07e] . . . . . . . . . . . . . . . . . . . . . . 27
4.3 Isoächen 3D . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.4 Vektordarstellung [aIVG07a] . . . . . . . . . . . . . . . . . . . 30
4.5 Volumendarstellung . . . . . . . . . . . . . . . . . . . . . . . . 31
4.6 3D-Cross-Section mit Schatten [aIVG07b] . . . . . . . . . . . 31
4.7 Datenauswahl . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.8 Kontextmenü-Maus . . . . . . . . . . . . . . . . . . . . . . . . 35
4.9 Kontextmenü . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.10 Werkzeugleiste . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.12 Favoriten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.13 Navigation [Goo07] . . . . . . . . . . . . . . . . . . . . . . . . 39
4.14 Objekt Aufschnitt . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.15 Screenshot [aIVG07b] . . . . . . . . . . . . . . . . . . . . . . . 42
5.1 Secondary Mainwindow . . . . . . . . . . . . . . . . . . . . . . 44
85
5.2 Teekanne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.3 Maus Navigation . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.4 Rotation ohne Verschiebung . . . . . . . . . . . . . . . . . . . 48
5.5 Rotation mit Verschiebung . . . . . . . . . . . . . . . . . . . . 48
5.6 Beleuchtung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.7 links - ohne Subsampling, rechts - mit Subsampling . . . . . . 52
5.9 Isoächen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.10 Schwellenwert setzen . . . . . . . . . . . . . . . . . . . . . . . 58
5.11 Tiny Cubes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.12 Georaster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.1 Beruf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.2 Erfahrung mit 3D . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.3 Erfahrung mit NinJo . . . . . . . . . . . . . . . . . . . . . . . 73
6.4 Bewertung der Anwendung . . . . . . . . . . . . . . . . . . . . 73
8.1 Screenshot Temperatur über den Alpen . . . . . . . . . . . . . 81

8.2 Screenshot Wolkenvereisung . . . . . . . . . . . . . . . . . . . 81
Pilottest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
A Test Nr. 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
B Test Nr. 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
C Test Nr. 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
D Test Nr. 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
E Test Nr. 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
F Test Nr. 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
G Test Nr. 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
H Test Nr. 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
86
Literaturverzeichnis
Tri-
Vis NG, Filmbeispiel
[aIVG07a] Innovative Visualisierungslösungen GmbH ask:
. http://www.askvisual.de/mpegs/enea/
enea_a.mpg, 2007. [Online; Stand 3. Dezember 2007].
Visu-
al3D
[aIVG07b] Innovative Visualisierungslösungen GmbH ask:
. http://www.askvisual.de/german_sites/visual3d.
html, 2007. [Online; Stand 3. Dezember 2007].
[Chl06] Chlebek, Paul: User Interface-orientierte Softwarearchitektur .

vieweg, 2006.
[Dör07] Dörner, Dr. Ralf: . Visualisierung

http://www.gdv.
informatik.uni-frankfurt.de/index.php?m=2&sm=3, 2007.
[Online; Stand 3. Dezember 2007].
[Enc97] Encarnacao, Jose: Graphische Datenverarbeitung 2 . R. Ol-

denbourg Verlag GmbH, 4. Auflage, 1997.
[Enc00] Encarnacao, Jose: Graphische Datenverarbeitung 1 . R. Ol-

denbourg Verlag GmbH, 4. Auflage, 2000.
[EuM07] EuMetSys: NinJo Workstation Project . http://www.

ninjo-workstation.com/, 2007. [Online; Stand 3. Dezember
2007].
[Goo07] Google: Google Earth . http://earth.google.de/, 2007. [On-

line; Stand 3. Dezember 2007].
[Hib07] Hibbard, Bill: VisAD . http://www.ssec.wisc.edu/~billh/

visad.html, 2007. [Online; Stand 3. Dezember 2007].
[Hop] Hopper, Edward: Bilder und Macht . 1 Auflage.
[Jun02] Jung, Dr. Volker: Design Visualisierung GOF . DWD, 2002.

[Dokument; Stand September 2003].
87
[Leh03] Lehmann, Martin: NinJo Course . DWD, 2003. [Folien; Stand
September 2003].
[Lex07] Lexikon, Meyers Online: Visualisierung . http://lexikon.

meyers.de, 2007. [Online; Stand 27. Juni 2007].
[Nie93] Nielsen, Jakob: Usability Engineering . Academic Press, 1993.
[QE07] Quint-Essenz: Interview http://www.quint-essenz.ch/de/

.
files/Interview_de_16.pdf, 2007. [Online; Stand 3. Dezember
2007].
[Sch03] Schnee, Gregor: Display of 3D data in NinJo . DWD, 2003.

[Folien; Stand 3. Dezember 2007].
Cross platform meteorological visualisation

at DWD
[Sch04] Schnee, Gregor:
. http://www.dwd.de/en/Zusammenarbeit/Kurse/
EGOWS/EGOWS2004_CrossPlatformVisualization_Schnee.pdf,
2004. [Online; Stand 3. Dezember 2007].
[War00] Ware, Colin: Information Visualization . Academic Press, 2000.
[Wet07a] Wetterdienst, Deutscher: GME http://www.dwd.de/de/

.
FundE/Analyse/Modellierung/, 2007. [Online; Stand 3. Dezem-
ber 2007].
LMK - DEVELOPMENT
OF A VERY-SHORT RANGE FORECAST MODEL http:
[Wet07b] Wetterdienst, Deutscher:
.
//www.meteo.fr/cic/wsn05/resumes_longs/6.04-500.pdf,
[Wet07c] Wetterdienst, Deutscher: Lokales Modell

http://www. .
dwd.de/de/FundE/Analyse/Modellierung/lm.htm, 2007. [On-
line; Stand 3. Dezember 2007].
[Wet07d] Wetterdienst, Deutscher: Modelle . http://www.dwd.de/

de/FundE/Analyse/Modellierung/, 2007. [Online; Stand 3. De-
zember 2007].
[Wet07e] Wetterdienst, Deutscher: Radar http://www.dwd.de/de/

.
Technik/Datengewinnung/Radarverbund/Grundprinzip.htm,
88
Dennis Gábor Wikipedia, Die freie Enzyklopä-
die
[Wik07a] Wikipedia:
. http://de.wikipedia.org/w/index.php?title=Dennis_
G%C3%A1bor&oldid=38586744, 2007. [Online; Stand 4. Dezem-
ber 2007].
[Wik07b] Wikipedia: IIOP Wikipedia, Die freie Enzyklopädie .

http://de.wikipedia.org/w/index.php?title=IIOP&oldid=
37961664, 2007. [Online; Stand 4. Dezember 2007].
[Wik07c] Wikipedia: Jogl Wikipedia, Die freie Enzyklopädie .
http://de.wikipedia.org/w/index.php?title=Jogl&oldid=
38851806, 2007. [Online; Stand 3. Dezember 2007].
89
90
Fragebögen
Pilottest
Persönliche Daten
• Berufsgruppe: Entwickler
• Erfahrung mit NinJo: seit 2 Jahren
• Erfahrung mit 3D-Anwendungen: ja

sicht her.

•
sinnvoll
Wie sinnvoll nden Sie die Anwendung?
•
für Volumendaten wie Wind
Für welchen Zweck würden Sie die Anwendung einsetzen?
•
intuitiv. Ich hätte nur erwartet, dass die Richtung des Zooms vertauscht
Wie nden Sie die Navigation?
ist.
91
•
keine
Welche Funktion vermissen Sie am meisten?
•
keine
Welche Anregungen haben Sie für die Anwendung?
Abbildung : Pilottest
92
A Test Nr. 1
Persönliche Daten
• Erfahrung mit NinJo: seit 2 Jahren

sicht her.

8
bis 10 (sehr gut)?
für die Analyse von meteorologisch markanten Wetterlagen

analyse)
•
das Ruckeln und ich vermisse eine Information, die mir sagt, um welche
Was stört Sie an der Navigation?
Achse ich die Szene rotiere

Am Wichtigsten wäre, dass möglichst viele Layer dreidimensional dar-

rungen, wie Farbe, zusätzliche Visualisierungen, wie Cross-Sections)
gestellt werden können.

93
•
keine
Abbildung A: Test Nr. 1
94
B Test Nr. 2
Persönliche Daten
• Berufsgruppe: Meteorologe
• Erfahrung mit NinJo: seit Juli 2007
• Erfahrung mit 3D-Anwendungen: nein

sicht her.

9
bis 10 (sehr gut)?
für Präsentationen und für die Interpretation von Radardaten

analyse)
•
nichts

die Darstellung von Radardaten

95
•
Man müsste Legenden haben, damit man sieht, welche Werte visuali-
siert werden. Eine transparente Darstellung der Isoächen sollte auch

möglich sein, damit man eine orthographische Zuordnung machen kann.
Abbildung B: Test Nr. 2
96
C Test Nr. 3
Persönliche Daten
• Erfahrung mit NinJo: seit 2000
• Erfahrung mit 3D-Anwendungen: nein

sicht her.

7 bis 8
bis 10 (sehr gut)?
für Präsentationen oder für eine genauere Analyse. weniger für einen
analyse)
schnellen ersten Eindruck

•
die verzögerte Reaktion auf die Maus

die Möglichkeit, die Farben einzustellen

97
•
Es wäre wichtig, nicht nur die Modellächen sondern auch die Druck-
ächen und deren Element zur Auswahl zu haben.
Abbildung C: Test Nr. 3
98
D Test Nr. 4
Persönliche Daten
• Erfahrung mit NinJo: seit 4 Monaten

sicht her.

2
bis 10 (sehr gut)?
für Präsentationen oder zur genaueren Analyse von Details

analyse)
•
Die Navigation ist ruckelig und kaum zu kontrollieren. Damit ist ein
echtes Arbeiten nicht möglich.

die Möglichkeit, bestehende Visualisierungen genauer einzustellen, zum

Beispiel durch das Ändern der Farben oder Einstellen von Transparenz
99
•
Es wäre gut, wenn man die Ansicht aufschneiden könnte und sich die-
sen Schnitt dann betrachten könnte.
Abbildung D: Test Nr. 4
100
E Test Nr. 5
Persönliche Daten

sicht her.

5
bis 10 (sehr gut)?
zur Analyse von Wettersituationen

analyse)
•
die Navigation ist in Ordnung

Es muss möglich sein, die P-Flächen darzustellen.

101
•
Ein höheres Subsampling wäre besser.
Abbildung E: Test Nr. 5
102
F Test Nr. 6
Persönliche Daten

sicht her.

10
bis 10 (sehr gut)?
Ich würde die Anwendung für alle Punkte einsetzen, am besten für die
analyse)
Detailanalyse.
•
Die Navigation wird mit der Zeit schlechter und die Maus reagiert zu
sensibel.
Man muss mehr Elemente anzeigen können.

103
•
Beim Wechseln der Visualisierungen in einem Layer sollen sinnvolle
Voreinstellungen geladen werden
Abbildung F: Test Nr. 6
104
G Test Nr. 7
Persönliche Daten

sicht her.

für Forscher 8, für den normalen Betrieb 3

bis 10 (sehr gut)?
zur Animation, wie zum Beispiel zum Wolkenug

analyse)
•
die vorhandenen Bugs, wie das aufpoppende Kontextmenü

mehr Einstellungsmöglichkeiten wie Farbe, Skalierung der Z-Achse, Be-

leuchtung
105
•
Wenn man in die Szene reinzoomt, wäre es praktisch, wenn die Daten
in der Nähe eine höhere Auösung hätten als die Daten in der Ferne.
Abbildung G: Test Nr. 7
106
H Test Nr. 8
Persönliche Daten
• Erfahrung mit 3D-Anwendungen: wenig

sicht her.

7
bis 10 (sehr gut)?
zur wissenschaftlichen Detailanalyse, aber auch zu Präsentationszwe-

analyse)
cken
•
Die Maus ist zu sensitiv eingestellt.

Die Überhöhung sollte einstellbar sein und mehr Daten sollten zur Aus-
wahl stehen.
107
•
Ein Panning ohne eine Drehung in 3D wäre gut.
Abbildung H: Test Nr. 8
108
Inhaltsverzeichnis CD
1. Diplomarbeit (PDF)
2. Diplomarbeit (TeX)
3. Quellcode
4. Quellen
5. Vortrag
109

Sprache

Diplomarbeit Markus Haßfurter

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Diplomarbeit Markus Haßfurter

Hochgeladen von

Copyright:

Verfügbare Formate

Diplomarbeit

Das automatische Mapping zweidimensionaler

Hans Joachim Koppert

Institut für Informatik

Oenbach, 16. Dezember 2007

Aufgabe Die Arbeit wird im NinJo-Kontext unter Nutzung der vorhan-

This Master's thesis is about the automatic mapping of two-dimensional me-

Assignment This Master's thesis will be implemented as a part of the

1.1 Motivation und Ziel

Grundlagen In diesem Abschnitt werden theoretische Grundlagen der Vi-

NinJo Hier wird die allgemeine Funktionsweise der NinJo-Workstation er-

Implementierung Hier werden Besonderheiten und Probleme betrachtet,

Nutzertest Durch die Konzeption, Durchführung und Auswertung der

Ausblick Es folgt ein Ausblick auf künftige Funktionen der Applikation.

1 siehe Bilder und Macht - Politiker im 20. Jahrhundert [Hop]

2.1.1 Was ist der Sinn einer Visualisierung?

Explorative Analyse - Theorie entwickeln Mit Hilfe einer explorativen

Konrmative Analyse - Theorie überprüfen Im Gegensatz dazu er-

Präsentation - Informationen vermitteln Mit Hilfe der Präsentation

2.1.2 Was ist eine gute Visualisierung?

eektiv Die Eektivität einer Visualisierung wird daran gemessen, ob die

angemessen Eine Visualisierung ist angemessen, wenn ihr Aufwand der

2.1.3 Grundlegende Visualisierungstechniken

Im Folgenden werden verschiedene Verfahren vorgestellt, um Daten auf Ob-

Geometrie Hier werden die Daten auf geometrische Eigenschaften eines

Textur Textur ist ein mächtiges Visualisierungsprinzip und dem Mapping

Objekte Glyphenbasierte Techniken werden häug eingesetzt. Ihr wich-

Graphiken werden für strukturelle Logik, örtliche Strukturen, zur besseren

2.2.2 Visualisierungspipeline für Volumendaten

2.2.3 Methoden der Volumenvisualisierung

Quadermethode (Tiny Cubes Method) Für jedes Volumenelement

xi = x0 + iδx (M + 1) und i = 1, ..., nx

Jedem Eckpunkt ist ein Farbwert b zugeordnet. Die Quaderächen werden

Abbildung 2.1: Quadermethode

Transparente Quadermethode (Vanishing Cube Method) Hierbei

Abbildung 2.2: Transparente Quadermethode

Dekomposition in Schichten (Slicing) Anstelle der trivariaten Funkti-

fi (y, z) = f (xi , y, z) mit i = 0, ..., (nx + 1)

dargestellt. Die Schnittebenen können in der Regel interaktiv ausgewählt und

Extraktion von Flächen

Abbildung 2.3: Schichtenmethode

Abbildung 2.4: Varianten der Schichtenmethode

Interpretationen suggeriert werden.

Segmentierung und einfache Approximation Nach der Festlegung ei-

innen - auf - auÿen

Extraktion von Flächen aus Zellen Wenn Isoächen beliebig innerhalb

Contouring and Connecting Beim Contouring and Connecting wer-

Abbildung 2.5: Contouring and Connecting

Das Problem bei verschiedenen Kontur-Topologien auf benachbarten Ebe-

• Eine interaktive Nutzereingabe erfolgt, um die Konturen zu spezizie-

• Ein Bereich mit Mehrdeutigkeiten wird in Teilbereiche unterteilt. Nun

• Es wird eine Kostenfunktion herangezogen, um eine Entscheidung zu

• Weitere Eigenschaften der Isolinien wie Form, Konvexität oder Orien-

Abbildung 2.6: Fallunterscheidungen beim Marching Cube

Abbildung 2.6 existiert eine Mehrdeutigkeit. Es gibt zwei Möglichkeiten für

Beim Marching Cube Algorithmus kann es zu folgenden Problemen kom-

1. Die Zellen werden wie folgt klassiziert:

• Innen-Zelle: Alle in der Zelle präsenten Datenwerte sind kleiner

• Auÿen-Zelle: Alle in der Zelle präsenten Datenwerte sind gröÿer

• Oberächenzelle: Die durch den Schwellenwert spezizierte Isoä-

2. Alle Oberächenzellen werden rekursiv unterteilt und erneut klassi-

3. Oberächenzellen nach dem letzten Unterteilungsschritt werden als Ober-

Marching Tetraeder Bei dieser Methode wandert anstelle eines Wür-

Oenbach, 16. Dezember 2007

Konrmative Analyse - Theorie überprüfen Im Gegensatz dazu er-

eektiv Die Eektivität einer Visualisierung wird daran gemessen, ob die

Objekte Glyphenbasierte Techniken werden häug eingesetzt. Ihr wich-

Jedem Eckpunkt ist ein Farbwert b zugeordnet. Die Quaderächen werden

Extraktion von Flächen aus Zellen Wenn Isoächen beliebig innerhalb

• Eine interaktive Nutzereingabe erfolgt, um die Konturen zu spezizie-

1. Die Zellen werden wie folgt klassiziert:

• Oberächenzelle: Die durch den Schwellenwert spezizierte Isoä-

2. Alle Oberächenzellen werden rekursiv unterteilt und erneut klassi-

3. Oberächenzellen nach dem letzten Unterteilungsschritt werden als Ober-

Der Isoächenalgorithmus, der in dieser Arbeit verwendet wird, benutzt Mar-

Kongurierbarkeit Alle Einstellungen, die man während seiner Arbeit

die Arbeit fortzusetzen. Die meisten Einstellungen können in der graschen

CORBA (Common Object Request Broker Architecture) deniertes Proto-

• Die Darstellung der Isoächen und Volumenkörper soll wahlweise im

Für die fachliche Spezikation ist es notwendig, die relevanten Metadaten

3D-Isoächen werden bei der Darstellung von Gitterdaten angewendet.

3D-Isoächen, Volumendarstellung und Cross-Sections wurden schon im Grund-

Abbildung 4.3: Isoächen 3D

Temperatur Als Standardvisualisierung wird die 3D-Isoächen-Darstel-