Wie bereits in Abschnitt 3.7 angedeutet, ist es mit Hilfe der in XML definierten Transformationssprache XSLT und einem Flash-Generator, der textbasierte SWFML-Dateien in bitcodierte Flash-Filme überführt, möglich, beliebige XML-Dateien ohne Programmierung oder die Verwendung einer grafischen Entwicklungsumgebung als Flash-Film zu visualisieren. Die eigentliche Präsentation der Daten spezifizieren XSLT-Stylesheets, deren Erstellung natürlich zeitaufwendig bleibt. Dennoch entfallen sämtliche Compilerläufe, die bei der direkten Verwendung des SWF-SDK für jede Layoutänderung notwendig wären. Außerdem steht leistungsfähige Software zum Lesen, Schreiben und zur Syntaxprüfung der verwendeten Daten kostenlos zur Verfügung.
Der genannte Entwurf geht davon aus, dass die Eingabedaten bereits in einem XML-Format vorliegen - das trifft jedoch (noch) sehr selten zu. Im Fall dieser Diplomarbeit sollen Wettervorhersagedaten grafisch dargestellt werden, die komprimiert in einem binären Dateiformat namens GRIB vorliegen, das zudem nur Rasterdaten enthält. Rasterdaten geben die Werte einer skalaren Größe an den Kreuzungspunkten eines regelmäßigen Gitternetzes an. Bei Wettervorhersagedaten kann dies z.B. die Temperatur oder der Luftdruck an der betreffenden Stelle sein. Die Kartendaten, die die Präsentation der Wetterdaten ergänzen sollen, verhalten sich ähnlich: Sie liegen als Vektorgrafiken vor, stehen jedoch nur im binären Shapefile-Format des Geoinformationssystems ARC/INFO zur Verfügung.
Die erste Aufgabe wird deshalb die Überführung der binären Wetter- und Kartendaten in eine XML-Repräsentation sein. Erst dann kann der angestrebte Mechanismus aus XML-Techniken und Flash-Generator (siehe Abbildung 3.6) eingesetzt werden.
Um die wahren Vorteile des Vektorgrafikformats Flash (vgl. Abschnitt 2.1) nutzen zu können, ist es unerlässlich, die Wettervorhersagedaten vom Rasterformat in Vektorgrafikobjekte zu konvertieren. Dieser Vorgang wird Vektorisierung genannt und fasst Punkte mit gleichem Skalarwert zu sogenannten Isolinien zusammen.
Weiterhin soll geklärt werden, welche Schritte erfolgen müssen, um raum- und zeitbezogene Daten für die Visualisierung vorzubereiten. Den zeitlichen Ablauf unterstützt Flash durch framebasierte Animationen. Die räumliche Komponente kann jedoch nur dargestellt werden, sofern die Koordinaten der Datenwerte in Pixel-Angaben (bzw. in Twips) umgerechnet werden. Die benötigten Operationen der 2D-Computergrafik sind elementare Transformationen und Clipping. Da außerdem weder die vorliegenden Karten- noch die Wetterprognosedaten auf der für Deutschland typischen Lambert-Projektion basieren, ist voher noch eine Änderung der Projektion erforderlich.
Den Abschluss dieses Kapitels bilden einige Gedanken zur Gestaltung der Ausgabe, d.h. zum Layout der Flash-Filme.
Ein Entwurf zur Visualisierung von raum- und zeitbezogenen Daten kann noch so allgemeingültig formuliert sein, eine Unterstützung beliebiger Dateiformate ist nicht realisierbar - daher die Verwendung von XML. Das hat zur Folge, dass Nicht-XML-Formate im ersten Schritt in eine XML-Sprache zu konvertieren sind - ein Vorgang, der individuell für jedes Eingabedatenformat erfolgen muss. Beispielhaft werden im Rahmen dieser Diplomarbeit zwei binäre Dateiformate verwendet.
Die Grundlage jeder Wettervorhersage bilden Umrisse von Ländern, Flussverläufe, Seen und Städte mit ihren Namen. Die Ortsangabe ,,Osnabrück`` ist vertrauter und kann leichter eingeordnet werden, als eine Koordinatenangabe der Form ,,52,27° nördlicher Breite, 8,07° östlicher Länge``. Sowohl Landkarten als auch Wettervorhersagedaten definieren Ortsangaben über ein Koordinatensystem, das aber für den Betrachter uninteressant ist, denn er orientiert sich an den bekannten Elementen der Landkarte: ,,Wie warm wird es morgen in Osnabrück?``
Dank des Systemwissenschaftlichen Instituts der Universität besteht Zugriff auf verschiedene Dateien, die die benötigten geografischen Gegebenheiten für Deutschland und Europa in der gewünschten Auflösung enthalten. Umrisse von Ländern und Seen sind als Polygone kodiert, Flüsse sind als Linienzüge abgelegt und Städte als einzelne Punkte. Das zugrundeliegende Koordinatensystem ist durchweg das geografische, das den Erdball in 360 Längengrade und 180 Breitengrade einteilt. östl. Länge
Die Dateien werden normalerweise mit dem Geoinformationssystem ArcView12 bearbeitet und sind sogenannte Shapefiles. Das Shapefile-Format besteht aus drei Dateien [ESRI1998]: Einer Hauptdatei (.shp), einer Indexdatei (.shx) und einer dBASE-Datei (.dbf). Die Hauptdatei enthält in Datensätzen variabler Länge die Beschreibung von Vektorgrafikobjekten. Unterstützt werden Punkte, Linien und Polygone. Die Einträge der Indexdatei verweisen auf die Struktur der Hauptdatei. Die dritte Datei, die dBASE-Datenbankdatei, enthält Datensätze mit Attributen zu den Grafikobjekten der Hauptdatei. Zwischen Attribut-Datensätzen und den Geometrie-Datensätzen besteht eine 1:1-Beziehung und Grafikobjekte und Attribute werden in beiden Dateien in derselben Reihenfolge definiert, wie in Tabelle 4.1 skizziert.
|
Tabelle 4.1: Beispiel für eine Shapefile mit Städten
Das Auslesen der Information aus den Shapefile-Dateien und die Kombination der geometrischen Formen mit ihren jeweiligen Attributen erleichert die kostenlose C-Bibliothek shapefile [Warm2000]. Sie stellt zwei Programmierschnittstellen (APIs) zur Verfügung, die die Erstellung einfacher C-Programme zum Lesen und Schreiben von ESRI Shapefiles unterstützen: Die SHP-API und die DBF-API. Ein Konverter, der Shapefiles in eine XML-Repräsentation übersetzt, lässt sich so recht einfach programmieren. Eine Plattformabhängigkeit durch dieses C-Programm ist kaum gegeben, da eine Erstellung von Landkartendaten im XML-Format nur ein einziges Mal erfolgen muss (im Gegensatz zur Konvertierung der binären Wettervorhersagedaten).
Die Wettervorhersage für Deutschland berechnet seit 45 Jahren der Deutsche Wetterdienst (DWD), eine staatliche Behörde [DWD2000]. Erst seit kurzer Zeit gibt es auch einige private Anbieter, die ihre Analysen aber wie der DWD ebenfalls nicht gebührenfrei abgeben. Kostenlos können aktuelle Vorhersagen z.B. aus den USA von einem Internetrechner des National Weather Service [NWS2000] heruntergeladen werden. Jedoch umfassen diese Wetterprognosedaten in einem Raster von 360*180 Punkten (entsprechend der Längen- und Breitengrade) die gesamte Erde, was für Deutschland etwa einem Rasterabstand von horizontal 70km und vertikal 110km entspricht.
Das Lokal-Modell des DWD berechnet die Wettervorhersage der nächsten zwei Tage für das Gebiet Mittel- und Westeuropa. Das Ergebnis umfasst Prognosewerte im Stundenabstand für ein hochauflösendes Raster von nur 7km Schrittweite mit 325*325 Prognosewerten je Stunde je Ausprägung (Temperatur, Niederschlag, Luftdruck, ...) [DWD1999]. Zu Testzwecken wurde für diese Diplomarbeit die Wettervorhersage für den 26.12.1999 angeschafft, ein Tag, an dem ein Orkantief das Wetter in Deutschland sehr wechselhaft gestaltete und der damit sehr unterschiedliche Wetterlagen widerspiegelt. Bei den Daten handelt es sich um vier verschiedene Datensätze für jede volle Stunde des Tages, die die prognostizierten Werte für Temperatur, Niederschlag, Bewölkung und Luftdruck enthalten. Jeder Datensatz ist in einer separaten Datei im GRIB-Format abgelegt.
GRIB (Gridded Binary) ist ein universelles, bitorientiertes Dateiformat für Rasterdaten, das Wetterdienste zur Speicherung und zum Austausch ihrer Daten nutzen. Es wurde von der World Meteorological Organization (WMO) als offener internationaler Standard definiert [WMO1998]. Die aktuelle Version ist seit 1990 die GRIB Edition 1. Der Vorteil des GRIB-Dateiformats ist, dass die Dateien im Durchschnitt um mehr als 50% kleiner als reguläre binäre Dateien sind.
Eine GRIB-Datei kann aus einem oder mehreren Datensätzen (Records) bestehen, die jeweils die Werte einer einzelnen Ausprägung bzw. eines einzelnen Parameters für die Punkte eines rechteckigen Rasters enthalten. Ein Record gliedert sich in sechs logische Sektionen (Sections), von denen zwei optional sind:
Verschiedene Decodierer ermöglichen das Lesen von GRIB-Dateien. Die umfangreichste Unterstützung von Parametertabellen und Rasterdefinitionen bietet das C-Programm wgrib [NCEP2000], ein Kommandozeilen-Programm, das das Inhaltsverzeichnis einer GRIB-Datei auflisten und wahlweise die Rasterdaten im ASCII-Format in Dateien speichern kann. Das Inhaltsverzeichnis der GRIB-Datei mit der Niederschlags-Vorhersage des DWD für den 26.12.1999, 15 Uhr lautet z.B.:
rec 1:0:date 1999122600 APCP kpds5=61 kpds6=1 kpds7=0 levels=(0,0) grid=255 sfc 0-15hr acc: bitmap: 975 undef APCP=Total precipitation [kg/m^2] timerange 4 P1 0 P2 15 TimeU 1 nx 325 ny 325 GDS grid 10 num_in_ave 0 missing 0 center 78 subcenter 255 process 132 Table 2 rotated LatLon grid lat 3.250000 to -17.000000 lon -12.500000 to 7.750000 nxny 105625 (325 x 325) dx 62 dy 63 scan 0 mode 128 transform: south pole lat -32.500000 lon 10.000000 rot angle 0.000000 min/max data 0 218 num bits 8 BDS_Ref 0 DecScale 0 BinScale 0
Da der C-Quellcode von wgrib verfügbar ist, werden im Rahmen der Realisierung (Abschnitt 5.3.2) die benötigten Passagen des Programms nach Java portiert und so umgeschrieben, dass eine direkte programminterne Weiterverarbeitung der Daten möglich ist .
Die Vektorisierung von Rasterdaten ist ein spezielles Gebiet der Computergrafik, das sich mit der Umwandlung von Rasterdaten in Vektordaten beschäftigt. Die häufigste Anwendung ist sicher die Konvertierung von Pixelgrafiken in Vektorgrafiken, für die inzwischen jedes umfangreichere Grafikprogramm ein Modul bereitstellt (CorelTrace von Corel, ArcScan für ARC/INFO, CAD Overlay für AutoCAD). Je leistungsfähiger die Vektorisierungssoftware, desto besser erkennt sie zusammenhängende Gebiete, Linien und Kreisbögen und erstellt daraus Vektorobjekte wie Polygone, Linien usw. Dieser Vorgang ist meistens sehr rechenintensiv und entsprechende Software kostet bis zu mehreren zehntausend Mark.
Besonders interessant ist der Einsatz von Vektorisierern für den CAD- und den GIS-Bereich, wo z.B. eingescannte topografische Karten oder CAD-Zeichnungen in den vektorbasierten Datenbestand übernommen werden sollen. Doch auch für die hier gestellte Aufgabe - die Visualisierung der Wettervorhersagedaten des DWD mit Macromedia Flash - ist es unverzichtbar, die Rasterdaten aus den GRIB-Dateien in Vektorgrafikobjekte umzuwandeln. Die Vorteile von Vektorgrafiken kamen bereits im Abschnitt 2.1 zur Sprache: Sie sind auflösungsunabhängig, zoomfähig und platzsparend.
GRIB-Dateien enthalten die Werte eines Parameters für ein reguläres rechteckiges Raster bzw. Gitter. Die Parameterwerte können deshalb für die weitere Verarbeitung in ein zweidimensionales Array eingelesen werden. Die Indezes der Rasterzellen wachsen dabei zeilenweise von oben nach unten und spaltenweise von links nach rechts. Die eigentlichen Positionen der Rasterpunkte auf der Erdoberfläche sind vorerst nicht von Interesse.
Jeder Rasterpunkt hat genau vier direkte Nachbarn, sofern er nicht am Rand liegt. Zwischen zwei benachbarten Rasterpunkten, d.h. auf einer Raster- oder Gitterkante, wird davon ausgegangen, dass sich der Wert des Parameters linear verhält: Der Wert steigt, fällt oder bleibt gleich. Zwischenwerte auf einer Gitterkante können durch lineare Interpolation berechnet werden, wie Abbildung 4.1 darstellt.
Die Aufgabe eines Vektorisierungsalgorithmus ist es, anhand vorgegebener Werte die entsprechenden Isolinien in diesem Raster zu finden. Isolinien sind Linienzüge, auf denen der Parameter einen konstanten Wert besitzt. Man erhält sie, indem benachbarte Punkte mit gleichem Parameterwert - Rasterpunkte oder linear interpolierte Punkte auf Gitterkanten - miteinander verbunden werden.
Isolinien kreuzen sich niemals, wie man sich an einem Beispiel wie in Abbildung 4.2 leicht klar machen kann oder auch von Höhenlinien auf Landkarten kennt. Sie werden eventuell komplett von anderen Isolinien umrundet, schneiden diese jedoch nicht. Die Fläche zwischen zwei Isolinien soll als Isofläche bezeichnet werden, sie enthält die Parameterwerte eines bestimmten Wertebereichs. Die Isoflächen sind die eigentlichen Elemente, die ein Vektorisierer im vorliegenden Fall als Resultat liefern soll. Repräsentiert als Polygone können die Wettervorhersagedaten eingefärbt und eventuell beschriftet in Flash visualisiert werden: Z.B. Temperatur zwischen 2,5°C und 5,0°C in hellblau.
Neben kostspieligen kommerziellen Applikationen zur Vektorisierung von Rasterdaten gibt es im Internet einige kostenlose Ansätze [Bour1987][Libe2000][Webe2000], die jedoch alle nicht den gewünschten Anforderungen entsprechen. Vielfach waren die Algorithmen auf Pixelgrafiken abgestimmt und verschmolzen lediglich gleichwertige Pixel miteinander. Für direkt benachbarte Bildpunkte liefert dieses Vorgehen zufriedenstellende Ergebnisse, nicht jedoch für ein Raster mit 7km Schrittweite. Erst mittels Interpolation auf den Gitterkanten erhält man die geforderten Isoflächen bzw. Isolinienzüge und nicht nur auf Rasterpunkten basierende Linien oder Flächen. Schwierigkeiten macht vielen Algorithmen vor allem auch das Einfärben von ineinander liegenden Isoflächen.
Im Folgenden sollen zwei Algorithmen zur Vektorisierung von Rasterdaten vorgestellt werden, die beide vom vorliegenden Sonderfall eines zweidimensionalen, vollständig besetzten rechteckigen Rasters ausgehen. Ein einfacher Algorithmus wurde bei einem ersten Ansatz verfolgt, musste aber anschließend verworfen werden, da er keine lineare Interpolation verwendet. Der zweite Algorithmus basiert auf einem Artikel der Association for Computing Machinery (ACM), bestimmt die Isolinienpunkte durch lineare Interpolation, muss aber für die vorliegende Aufgabe noch erweitert werden, um das korrekte Einfärben der Isoflächen zu ermöglichen.
Als ,,lauwarm`` bezeichnete der unbekannte Autor seinen Algorithmus [Card1999], verfolgt aber einen interessanten Ansatz. Die grundlegende Idee ist die Darstellung jedes Rasterpunktes als vektorielles Rechteck, d.h. jeder Punkt wird im ersten Schritt von vier geradlinigen Vektoren im Uhrzeigersinn umlaufen. Jeder Vektor kennt dabei seinen Vorgänger und Nachfolger (siehe Abbildung 4.3a).
Alle Vektoren (vier je Rasterpunkt) werden dem Parameterwert am Rasterpunkt entsprechend in eine Liste eingetragen, so dass es für jeden möglichen Wert des Parameters eine Liste von Vektoren gibt. Alternativ können die Vektoren auch nach Wertebereichen des Parameters einsortiert werden. In Abbildung 4.3 sind die zum Wert 5.0 gehörigen Vektoren blau und die des Rasterpunktes mit Wert 4.0 rot dargestellt.
Ausgangssituation |
Eliminierung |
Optimierung |
Im nächsten Schritt werden je Vektorenliste alle Vektoren untereinander verglichen. Beschreiben zwei Vektoren dieselbe Strecke in entgegengesetzter Richtung, stehen sie zwischen zwei Rasterpunkten, an denen der Parameterwert identisch ist (bzw. aus demselben Wertebereich stammt). Die umlaufenden Vektoren der beiden Rasterpunkte können miteinander zu einem größeren Rechteck verschmelzen, das anschließend zwei Rasterpunkte umläuft. Dies geschieht, indem die Grenzvektoren deaktiviert werden und die Verzeigerung ihrer Vorgänger bzw. Nachfolger geändert wird.
Durch die Wiederholung dieses Vorgangs verschmelzen alle benachbarten Rasterpunkte mit identischem Wert bzw. desselben Wertebereichs zu einer Fläche, die von vielen einzelnen Vektoren umlaufen wird (siehe Abbildung 4.3b). Dabei werden nur die Nachbarn entsprechend des 4-way-stepping berücksichtigt.
Bei einer abschließenden Optimierung können aufeinanderfolgende Vektoren, die in dieselbe Richtung zeigen, als ein verlängerter Vektor geschrieben werden (siehe Abbildung 4.3c).
Der Algorithmus erzeugt Polygone, die sich aus Geraden zusammensetzen, die in nur vier Richtungen (oben, links, rechts, unten) verlaufen können. D.h. es entstehen ,,Klötzchen``-Polygone, die nicht viel besser als Pixelgrafiken wirken. Die fehlende Interpolation auf den Gitterkanten begründet die Ungenauigkeit des Algorithmus und führte dazu, dass er schliesslich verworfen wurde.
Der Artikel ,,Algorithm 531 - Contour Plotting`` [SnyW1978] wurde 1978 von William V. Snyder bei der Association for Computing Machinery (ACM) eingereicht. ,,Contour Plotting`` beschreibt allgemein das Zeichnen von Umrisslinien bzw. Isolinien.
Snyder geht bei seinem Artikel von einem zweidimensionalen Array mit skalaren Werten und von vorgegebenen Isowerten aus. Er beschreibt zwei mögliche Vorgehensweisen, wie die gesuchten Isolinien zu finden sind. Prinzipiell gibt es die beiden folgenden Ansätze:
Sein line-following-Algorithmus lässt sich in die folgenden Schritte einteilen:
Der Algorithmus liefert durch die Interpolation im Vergleich zum einfachen Algorithmus (Abschnitt 4.2.1) viel bessere Ergebnisse. Zu beantworten ist noch die Frage, wie die Flächen zwischen den Isolinien gefüllt werden können.
Der Algorithmus von Snyder gibt die gefundenen Isolinien direkt auf einen Drucker oder Bildschirm aus und erstellt keine programminterne Repräsentation der Linien. Geschlossene Linienverläufe entstehen nur für Isolinien, die nicht an den Rand des Rasters stoßen. Außerdem erhält man keine Auskunft über die Bereiche zwischen den Isolinien und die daraus resultierende Füllfarbe der Flächen. Das Fazit lautet: Snyders Algorithmus erstellt lediglich Isolinien jedoch keine Isoflächen. Der Algorithmus kann als Bestätigung dienen, dass eine Aufsplittung der Gitterzellen in Dreiecke - so lauteten erste Überlegungen zu diesem Thema - nicht notwendig ist. Jedoch muss ein eigener Algorithmus anhand der genannten Ideen entwickelt werden.
Um aus Rasterdaten Isoflächen zu erzeugen, müssen die Isolinien in programminternen Datenstrukturen abgelegt werden und weiterhin zur Verfügung stehen. Denn zu bedenken ist, dass jede Isolinie zwei Isoflächen voneinander abgrenzt. Jede Isolinie gehört zur Umrisslinie von zwei aneinandergrenzenden Isoflächen. Liegt eine Isofläche komplett in einer anderen, so muss in die äußere ein Loch geschnitten werden, so dass ein ,,Donut`` entsteht. Ein solcher Ring lässt sich mit einem Polygon, d.h. mit einem einzigen Linienzug, nur durch eine unsichtbare Verbindung zwischen äußerer und innerer Begrenzung erreichen (siehe Abbildung 4.5). Flash bietet diese Möglichkeit.
Isoflächen ohne Loch, die keinen Kontakt mit dem Rand haben, die also von einer anderen Isofläche umgeben sind, werden von einer geschlossenen Isolinie begrenzt. Isoflächen, die dagegen teilweise vom Rand des Rasters begrenzt werden, besitzen keine Umrisslinie, die nur aus den Punkten eines Isowertes besteht. Ihre äußere Begrenzungslinie setzt sich abwechselnd aus Randstücken und Isolinien zusammen, wobei die Isolinien beliebig zu beiden Isowerten gehören können, die den Wertebereich der Isofläche begrenzen. Ein Beispiel: Die dunkelgrüne Isofläche aus Abbildung 4.2 spiegelt den Wertebereich 5.0-7.5°C wider. Sie wird begrenzt von den Isowerten 5.0°C und 7.5°C. Ihre Begrenzungslinie setzt sich aus drei Randstücken und zwei Isolinien mit dem Wert 5.0°C und einer Isolinie mit dem Wert 7.5°C zusammen.
Ein Algorithmus, der diese Gegebenheiten berücksichtigt und als Ergebnis Isoflächen bzw. Polygone sortiert nach ihrem Wertebereich liefert, lautet:
Der Algorithmus liefert in Listen von Polygonen die Isoflächen getrennt nach ihren Wertebereichen und damit ihren Füllfarben. Snyders ursprünglicher Algorithmus ist kaum wiederzuerkennen. Abbildung 4.9 zeigt in einem Flussdiagramm noch einmal die Abfolge der einzelnen Schritte.
Schneidet eine Isolinie alle vier Kanten einer Gitterzelle, ist der Verlauf der Isolinie nicht eindeutig, da sich derselbe Isowert auf allen vier Kanten befindet. Anhand der Position der Schnittpunkte auf der oberen und der unteren Kante wird in diesem Fall entschieden, welche Verbindungen gewählt werden: Ist der x-Wert auf der oberen Zellkante kleiner als auf der unteren Zellkante, erfolgt die Verbindung unten-rechts und oben-links. Abbildung 4.10 zeigt den Sachverhalt anhand derselben Gitterzelle für zwei unterschiedliche Parameterwerte (z.B. Temperatur) in der linken oberen Ecke.
Da die Erde von sehr komplexer Form ist, gehört es zu den Hauptaufgaben der Geodäsie (Vermessungskunde), die Figur unseres Planeten zu bestimmen. Zur Abstraktion und Vereinfachung der Erdoberfläche werden geodätische Bezugssysteme, wie z.B. die mathematischen Bezugsflächen Kugel und Rotationsellipsoid, eingeführt. Um die Position in einem solchen Bezugssystem zu beschreiben, verwendet man Koordinaten, die einem Koordinatensystem zugeordnet sind [Vose1998].
Auch in den zur Verfügung stehenden Shapefiles und den GRIB-Dateien erfolgen
Positionsangaben über zweidimensionale Koordinaten. Denn legt man eine Kugelgestalt
der Erde zugrunde, können alle Punkte der Erdoberfläche durch zwei Parameter,
die sogenannte geografische Länge u und die geografische Breite
v, eindeutig (bis auf die Pole, denen keine eindeutige geografische Länge zugeordnet
werden kann) festgelegt werden. Eine Parameterdarstellung der Erdkugeloberfläche
in diesen beiden Parametern hat die Form
Werden die geografischen Koordinaten direkt als Abszissen- und Ordinatenwerte eines zweidimensionalen Koordinatensystems dargestellt, kommt es zu starken Verzerrungen in Richtung der Pole. Die Kartografie beschäftigt sich mit der nicht trivialen Aufgabe, durch Kartenprojektionen - auch Kartenentwürfe genannt - die Oberfläche der Erdkugel in eine Ebene abzubilden. Da es unmöglich ist, Karten zu konstruieren, die ein exaktes Abbild der Erdoberfläche darstellen [Hosc1984], werden Projektionsflächen gewählt, die das abzubildene Gebiet möglichst gut approximieren. Dabei werden Tangentialebenen, Kegel und Zylinder oder komplexe mathematische Flächen verwendet, die in eine Ebene abrollbar sind. Eine Abbildung direkt in die Ebene wird azimutale Abbildung oder azimutaler Entwurf genannt, bei Abbildungen auf einen Zylinder spricht man von einem Zylinderentwurf, während Abbildungen auf einen Kegel als Kegelentwurf oder konische Abbildung bezeichnet werden. Abbildung 4.12 veranschaulicht diese drei Möglichkeiten.
Aus Sicht des Anwenders einer Karte sind die folgenden Eigenschaften der angewandten Projektion wünschenswert. Eine mathematisch exakte Definition der Begriffe ist entsprechenden Lehrbüchern zur Differentialgeometrie zu entnehmen.
Eine typische Projektion für die Darstellung einer Deutschlandkarte ist der flächentreue azimutale Entwurf von Lambert (1728-1777) mit geeigneter Wahl der Entwurfsachse. Es handelt sich um eine flächen- und winkeltreue Projektion, die Perspektive wird jedoch verzerrt. Die Verzerrung ist am Zentrum (dem Berührpunkt) gleich Null , steigt aber mit der Entfernung davon an. Lamberts Entwurf sollte deshalb nicht für mehr als eine Hemisphäre angewendet werden. Abbildung 4.13 stellt die Konstruktion des Entwurfs für den Fall dar, dass die Entwurfsachse der Polachse entspricht.
Die Entwurfsachse läuft bei einem azimutalen Entwurf durch den Erdmittelpunkt und den Berührpunkt der Tangentialebene an die Kugel. Für eine Deutschlandkarte bietet sich z.B. die geografische Lage von Eisenach in Thüringen als Berührpunkt der Projektionsebene an, da die Stadt ungefähr in der Mitte des Landes liegt und die Verzerrungen so gleichmäßig zum Kartenrand hin zunehmen.
Die Projektion eines grafischen Objekts (z.B. ein Isoflächen-Polygon oder die geografische Lage einer Stadt) wird durch das Projezieren seiner einzelnen Definitionspunkte erreicht. Die Formeln zur Berechnung der Bildkoordinaten des flächentreuen azimutalen Entwurfs von Lambert bei allgemeiner Lage der Entwurfsachse lauten [SnyJ1987]:
Wie zu Beginn vereinbart, bezeichen und die geografische Länge bzw. Breite. Die Koordinaten des Berührpunkts gibt das Tupel an. Als Bildbereich erhält man Werte zwischen -2 und 2 für beide Koordinaten.
Abbildung 4.14 stellt abschließend für eine einfache Deutschlandkarte die direkte Übertragung der geografischen Koordinaten der Erdoberfläche in die Ebene und die durch die Lambert-Projektion erlangte Darstellung gegenüber. Der Berührpunkt der Projektionsebene ist markiert.
Geografische Koordinaten |
Lambert-Projektion |
Zur endgültigen Darstellung der vorliegenden Landkarten- und Wetterdaten müssen weitere Operationen aus dem Bereich der Computergrafik angewendet werden. Für die Umwandlung beliebiger Koordinaten in Pixel des Flash-Films werden die elementaren zweidimensionalen Transformationen benötigt, zu denen Translation, Skalierung und Rotation zählen. Mit der Auswahl eines gewünschten Darstellungsbereichs befasst sich das Clipping.
Wie schon beim Thema Kartenprojektion angedeutet, wird die Manipulation der Darstellung bei grafischen Objekten allgemein durch mathematische Operationen auf den Definitionspunkten der Objekte beschrieben. Transformationen lassen sich deshalb durch Operationen auf den einzelnen Definitionspunkten beschreiben. Die elementaren zweidimensionalen Transformationen lauten nach Fellner [Fell1992]:
Unter Translation versteht man eine geradlinige Verschiebung eines
Objekts bzw. seiner Definitionspunkte. Die Koordinaten des verschobenen Punktes
berechnen sich aus der ursprünglichen Position
und einem Translationsvektor
durch
Mit Skalierung (Scaling, Zooming) wird die Vergrößerung bzw. Verkleinerung
von Grafikobjekten bezeichnet. Die transformierten Koordinaten
des Punktes werden mit den Skalierungsfaktoren
anhand der Formel
Eine Skalierung bewirkt, dass sich der Abstand jedes Punktes vom Ursprung des Koordinatensystems (allgemeiner vom Fixpunkt) entsprechend der Skalierungsfaktoren ändert. Die Wahl eines beliebigen Fixpunktes wird durch eine Aneinanderkettung von Transformationen erreicht: Translation um , Skalierung mit bezüglich des Ursprungs und anschließende Rücktranslation um .
Die Rotation eines Grafikobjekts wird durch den Rotationswinkel festgelegt. Die Rotationsformel für den Punkt lautet
Allgemein ist darauf zu achten, dass geometrische Objekte durch Transformationen ihren Typ ändern können. Soll zum Beispiel ein Rechteck, das nur durch zwei gegenüberliegende Eckpunkte definiert ist, gedreht werden, so bleibt seine Form im Allgemeinen nur erhalten, wenn es vor der Drehung in ein Polygon mit vier Eckpunkten umgewandelt wird. Die beschriebene Situation tritt im Rahmen der vorliegenden Diplomarbeit nicht ein, da nur Polygone, Linien und Punkte verwendet werden.
Nicht nur durch die Wahl eines beliebigen Fixpunktes bei der Skalierung oder eines beliebigen Zentrums für die Rotation kommt es häufig vor, dass eine Folge von unterschiedlichen Transformationen auf ein Grafikobjekt angewendet werden soll. Anstatt alle elementaren Transformationen einzeln auf jedem Definitionspunkt auszuführen, bietet die Anwendung von Matrizenmethoden einen effizienteren Ansatz.
Die Einführung von homogenen Koordinaten erlaubt die Darstellung der
Transformationsgleichungen in einer einheitlichen Matrixform. Jeder Punkt
bekommt die homogene Koordinatenschreibweise
zugeordnet,
wobei einen Wert ungleich Null besitzt und
Die Transformationen werden durch 3x3-Matrizen dargestellt, so dass sich sowohl die Transformation eines Punktes als auch die Verknüpfung von Transformationen als Matrizenmultiplikation realisieren lässt. Die Matrizen werden dabei jeweils von rechts an den homogenen Vektor oder die Matrix einer vorhergehenden Transformation multipliziert. Die elementaren Transformationen Translation, Skalierung und Rotation lauten in Matrixschreibweise:
Die Transformationsmatrix für eine Rotation um 90° bezüglich des Punktes lautet beispielsweise
Der Vorteil der Matrixschreibweise ist, dass für eine Folge von Transformationen zuerst die Transformationsmatrizen multipliziert werden, bevor die Koordinaten eines Grafikobjekts modifiziert werden. Dadurch wird die Anzahl der Berechnungsschritte gegenüber der sequentiellen Ausführung der einzelnen Transformationen erheblich reduziert. Der Ansatz hilft außerdem, Rundungsfehler zu vermeiden, da nicht nach jeder einzelnen Transformation ein (eventuell ganzzahliges) Ergebnis berechnet werden muss.
Eine Herleitung von dreidimensionalen Transformationen lässt sich durch Hinzunahme einer dritten Koordinate für die z-Richtung relativ einfach aus den genannten zweidimensionalen Transformationen vollziehen. Nur die Beschreibung der 3D-Rotation ist etwas aufwendiger, da ein Grafikobjekt im dreidimensionalen Raum um jede beliebige Achse gedreht werden kann.
Eine Verallgemeinerung der vorgestellten Transformationen stellen die affinen Abbildungen dar. Sie werden jedoch im Rahmen dieser Diplomarbeit nicht benötigt und werden deshalb nicht vertieft.
Die Wettervorhersagedaten des DWD umfassen nicht nur Deutschland, sondern einen grossen Teil Westeuropas (325*325 Rasterpunkte mit einem Abstand von 7km bedecken eine Fläche von 2275*2275km). Das Beschneiden der Daten auf einen gewünschten rechteckigen Bereich - auch Fenster genannt - beschreiben sogenannte Clipping-Algorithmen. Diese Algorithmen entfernen Grafikobjekte, die außerhalb des Fensters liegen und beschneiden Objekte, die nur teilweise im sichtbaren Ausschnitt liegen. Dadurch kann die Menge der zu verarbeitenden Daten je nach Fenstergröße eventuell erheblich reduziert werden.
Für einzelne Punkte ist es einfach zu bestimmen, ob sie innerhalb des erlaubten
Bereichs liegen. Das Fensterrechteck ist durch die Eckpunkte
und
eindeutig bestimmt und ein Punkt liegt
innerhalb der Fenstergrenzen, sofern
Komplizierter ist bereits das Clipping von Linien. Denn eine Linie beschreibt eine Strecke zwischen zwei Punkten, die keinen, einen oder zwei Schnittpunkte mit den Fensterkanten haben kann. Existiert kein Schnittpunkt von Linie und Fensterkante, liegt die Linie komplett innerhalb oder komplett außerhalb des Fensters. Bei einem Schnittpunkt liegt einer der Definitionspunkte der Linie innerhalb, der andere außerhalb des Ausschnitts. Existieren zwei Schnittpunkte, liegen beide Definitionspunkte außerhalb des sichtbaren Bereichs. Die Linie verläuft aber durch das Fenster.
Ein auf Cohen und Sutherland zurückgehender Algorithmus unterteilt die Ebene anhand der Clipping-Grenzen (den Fensterkanten) in 9 Bereiche (siehe Abbildung 4.15) und ordnet den Definitionspunkten den jeweiligen Bereichscode zu.
Die Bits der Bereichscodes ermöglichen effiziente Tests auf die Sichtbarkeit
von Linien. Gilt die Formel
Für das Clipping von Polygonen reicht es nicht aus, das Linien-Clipping sequentiell auf die Kanten des Polygons anzuwenden. Das Polygon kann in mehrere unzusammenhängende Teile zerfallen, wie Abbildung 4.16b zeigt.
Stattdessen müssen zusätzlich die Ein- und Austrittspunkte verbunden werden, wobei die Ecken des Clipping-Fensters eine Spezialbehandlung erfordern. Die Abbildungen 4.16c veranschaulicht diese Problematik.
Der Polygon-Clipping-Algorithmus von Sutherland und Hodgman [SuHo1974] clippt daher das gesamte Polygon an den vier Fensterkanten nacheinander, anstatt jede Kante des Polygons dem Clipping-Prozess zu unterwerfen:
foreach
Clipping-Gerade G do
foreach
Polygonpunkt
do
if (
sichtbar )
if (
schneidet G )
Eine ausführlichere Behandlung der beschriebenen Transformationen und Clipping-Algorithmen findet sich in [Fell1992].
Die vorherigen Abschnitte stellen die benötigten Methoden zur Verfügung, um aus den Rasterdaten des Deutschen Wetterdienstes Isoflächen zu generieren und diese mitsamt der Landkarten aus dem GIS-Bereich in eine Projektion zu bringen, die dem Anwender vertraut ist. Durch verschiedene Transformationen der Grafikobjekte und die abschließende Wahl eines gewünschten Ausschnitts können die vorliegenden Daten nun in einem XML-Format gespeichert werden, das direkt vom geplanten Visualisierungsprozess (vgl. Abbildung 3.6) unter Zuhilfenahme eines geeigneten XSLT-Stylesheets verarbeitet werden kann.
Für die Vervollständigung des Datenflusses von GRIB-Dateien und GIS-Daten zu animierten Flash-Filmen fehlt nur noch der Inhalt des XSLT-Stylesheets, d.h. die Umsetzung von Temperaturflächen und -isolinien, Landkartenumrissen, Flüssen und Städten in eine grafische Darstellung. Das Stylesheet enthält - wie bereits der Name sagt - die Gestaltung der Ausgabe.
Von Anfang an wurde mit den aus den Rasterdaten erzeugten Polygonen eine flächendeckende Darstellung der Wetterdaten angestrebt. Denn die stattdessen häufig verwendeten punktuellen Angaben von Temperatur und Niederschlag (z.B. 5°C in Berlin) fordern die Fähigkeiten von Macromedia Flash nicht heraus. Außerdem enthalten die vorliegenden Wetterdaten viel präzisere Werte, die dem Anwender nach Bedarf zur Verfügung stehen sollen, so dass z.B. selbst ein Einwohner eines Dorfes in der Lüneburger Heide die exakte Vorhersage für seine Region abfragen kann.
Flash unterstützt das zusätzliche Einblenden von Informationen durch verlustfreies Zoomen - Ausschnitte können vergrößert betrachtet werden - und die Skriptsprache ActionScript. Durch Interaktion mit dem Benutzer können über ActionScript-Anweisungen die Darstellung von Landkartenmerkmalen geregelt und mehrere Ebenen mit unterschiedlichen Wetterinformationen ein- und ausgeblendet werden. Die Kombination von Ebenen in beliebiger Reihenfolge ist ebenfalls denkbar.
Zusätzlich kann eine detailliertere Darstellung z.B. durch einen Kachelungs-Mechanismus erreicht werden.13 D.h. hinter der Grafik einer Einstiegsseite, die dem Benutzer bereits einen Überblick verschafft, verbergen sich für vorgegebene Ausschnitte präzisere Flash-Filme, die durch Hyperlinks innerhalb der Startgrafik gewählt werden können. So erhält der Internetnutzer für den von ihm gewählten Bereich (für eine Kachel) in einem weiteren Flash-Film alle zur Verfügung stehenden Informationen, muss aber nicht für die gesamte Wettervorhersagekarte die höchte Detailstufe aus dem Internet herunterladen. Kachelungs-Mechanismen reduzieren die Warte- und Onlinezeit des Benutzers. Wichtig ist, dass sich die Kacheln überlappen, so dass keine Stelle der ursprünglichen Karte nur auf einer Kante zu liegen kommt.
Die meisten der oben genannten Gestaltungsmöglichkeiten sind jedoch Thema der bereits erwähnten Diplomarbeit meines Kommilitonen Ralf Kunze. Eine Benutzeroberfläche zur Steuerung der Sichtbarkeit von Ebenen mit unterschiedlichen Parametern und zur Beeinflussung der Animation wird ebenfalls von ihm entwickelt werden.
Im Rahmen der vorliegenden Arbeit werden Flash-Filme die Daten des DWD - Temperatur, Niederschlag, Luftdruck und Bewölkung - vorerst nur in einer Art Diashow präsentieren. Eine spätere Integration von Kachelung und ActionScript ist jedoch vorgesehen. Ebenso ist beim Entwurf der Gestaltung der einzelnen Parameter darauf zu achten, dass später die Darstellung möglichst beliebiger Kombinationen der Ebenen möglich ist.
Für die Visualisierung von Temperaturwerten bieten sich Flächen mit einer Füllfarbe der Farbskala von lila für sehr kalte Zonen über blau, grün und gelb zu orange und rot für sehr hohe Temperaturen an. So kennt der Anwender die grafische Darstellung von Temperaturbereichen aus Zeitungen und der Tagesschau.
Die Gestaltung der Bewölkung ist ebenfalls leicht zu entwerfen. Da sich bei Flash alle Farben aus einem RGB-Wert und einem zusätzlichen Alphakanal zusammensetzen, der die Transparenz der Farbe, d.h. den Grad der Durchsichtigkeit, festlegt, können Wolken mit zunehmender Dichte durch einen höheren Deckungsgrad visualisiert werden. Wolken werden typischerweise als weiße Flächen und bei besonders starker Bewölkung in Grautönen dargestellt.
Die Menge des Niederschlags repräsentieren auf Klimakarten normalerweise farbige Flächen in den Farben rosa oder hellbraun für keinen Niederschlag über blau zu lila für hohen Jahresniederschlag. Wetterkarten im Fernsehen verwenden stattdessen für die Niederschlagsvorhersage animierte Regentropfen oder Schneeflocken. Für die Kombination mit anderen Parametern kommt alternativ auch eine Füllung der Flächen mit einem Muster in Frage, das je nach Stärke des Niederschlags kleinere Punkte (Tropfen) mit großen Abständen bzw. größere Punkte mit kleineren Abständen verwendet.
Luftdruck wird üblicherweise durch Isobaren14, d.h. Linienzügen mit der Angabe des jeweiligen Isowertes, beschrieben. Prinzipiell ist auch für alle anderen Parameter eine solche Darstellung denkbar, wenn statt gefüllten Isoflächen nur deren Umrisse ausgegeben werden, für den Luftdruck ist sie jedoch typisch.