Schneevisualisierung

Visualisierung der weltweiten Schneebedeckung von Florian Schulz, Julian Stahnke und Lionel Michel im Wintersemester 2012/13 an der FH Potsdam.
Betreut durch Markus Paeschke und Sebastian Meier im Kurs Map Interfaces.
Zugang zu den Daten durch Abror Gafurov vom Geoforschungszentrum in Potsdam.

Das Problem

Zur Vorhersage von Klima- und Wetterveränderungen werden aussagekräftige und vielseitige Daten benötigt. Während Wetterstationen umfangreiche und genaue Daten für einen bestimmten Ort auf der Welt liefern, bieten Satellitenbilder die Möglichkeit großflächige Veränderungen zu erkennen.

Jedoch können Wissenschaftler bislang nicht erkennen was sich unter einer Wolkendecke befindet. Und somit können sie auch nicht immer wissen, an welchen Orten Schnee liegt. In Anbetracht der wachsenden Bedeutung von Trinkwasser wird es allerdings immer wichtiger Voraussagen über die Verfügbarkeit von Wasser zu machen und Entscheidungen über den Umgang mit Schmelzwasser zu treffen. Kann man das Wasser in einem Staudamm energiebringend abfließen lassen oder sollte man es für eine kommende Trockenzeit sichern?

Durch einen Algorithmus von Abror Gafurov ist es nun möglich die Wolken aus Satellitenbildern herauszurechnen und mit Hilfe unserer Visualisierung die Schneebedeckung auf der Erde abzulesen.

Halbwegs wolkenfreie Sicht auf Südeuropa. Da die NASA nur ein Bild der gesamten Erde pro Tag bereitstellen kann, ist es dem Wetter überlassen, ob man die Schneebedeckung sehen kann oder nicht. Was befindet sich unter der Wolkendecke? [→ Foto auf Flickr](http://www.flickr.com/photos/neave/380825879/ „Bildquelle“)

Der Algorithmus von Abror Gafurov liefert zweifarbige wolkenfreie Bilder. Daran kann man sehen ob irgendwo Schnee liegt. Für die Visualisierung war dieses GeoTiff-Format jedoch nicht geeignet.

Codierung der Informationen in einem ASCII-Raster. Jeder Wert repräsentiert dabei eine Geoposition und gibt an, ob Schnee liegt (200), kein Schnee liegt (25) oder keine Daten vorhanden sind (50). Dieses Format war Ausgangspunkt für die Erstellung der PostgreSQL-Datenbank.

Referenzprojekte

Abror hatte uns im Vorfeld schon seine Visualisierungen der Daten gezeigt. Die waren zwar präzise, visuell wollten wir da aber noch etwas mehr herausholen.

Schneevisualisierungen aus einem wissenschaftlichen Paper zum ModSnow-Algorithmus von Abror.

Eine gute Methode um zwei Bilder (Vorher, Nachher) miteinander zu vergleichen. Mit der Maus kann die Teilung der Bilder, die übereinander liegen, bestimmt werden.
[http://www.abc.net.au/news/specials/japan-quake-2011/](http://www.abc.net.au/news/specials/japan-quake-2011/ „http://www.abc.net.au/news/specials/japan-quake-2011/“)

Wir schauten uns auch 3D-Visualisierungen an, die eventuell nützlich gewesen wären. Hauptproblem bei der Arbeit mit Terrain war nämlich, dass die Visualisierung stets die Höheninformationen überlagern würden. 3D-Visualisierungen können das zwar lösen, bringen wiederum aber andere Probleme der Interaktion und Lesbarkeit mit sich. [http://senseable.mit.edu/livesingapore/visualizations.html](http://senseable.mit.edu/livesingapore/visualizations.html „http://senseable.mit.edu/livesingapore/visualizations.html“)

Ziel

Im Gegensatz zu Informationsvisualisierungen ging es diesmal nicht darum ein bestimmtes Thema zu erklären und eine Geschichte zu erzählen, sondern darum, ein Werkzeug zu erstellen mit dem Daten visualisiert und zugänglich gemacht werden.

Im Endeffekt liefern wir ein Tool zur geografischen und zeitlichen Auswahl von Daten, die dann zur weiteren Verarbeitung heruntergeladen werden können. Eine interaktive Zeitleiste, die die prozentuale Schneebedeckung in verschiedenen Höhenlagen darstellt, und eine topografische Karte mit einer eingezeichneten Schneebedeckung beeinflussen sich dabei gegenseitig in ihrer Darstellung.

Nach Diskussion mit Abror wurden wir zudem in unserem Vorhaben bestärkt mit Small Multiples, also dem Vergleich von mehreren zeitlichen oder geografischen Ausschnitten, zu arbeiten.

Karte

Nachdem wir schnell realisiert haben, dass eine helle Karte nicht funktioniert, da wir darauf den weißen Schnee nicht gut darstellen könnten, fiel die Wahl auf dunkel-blaues Farbschema. Mit Hilf von Höheninformationen haben wir eine topografische Karte in TileMill erstellt. Zur weiteren Orientierung in den Gebirgen haben wir auch noch Höhenlinien in hohen Zoomstufen integriert. Diese geben zusätzliche Detailtief und lenken etwas von der niedrigen Auflösung der Höhendaten ab. Weiterhin gehören Markierungen der Städte und Flüsse natürlich zum Standardrepertoire einer Karte.

Terrain-Daten in TileMill. In diesem [Tutorial](http://mapbox.com/tilemill/docs/guides/terrain-data/ „http://mapbox.com/tilemill/docs/guides/terrain-data/“) wird erklärt wie man das macht.

Screenshot aus TileMill. Die Höhendaten haben wir monochrom gestaltet und somit die Prägnanz reduziert. Zudem mussten wir dafür sorgen, dass Labels für Städte, Länder und andere Markierungen bei bestimmten Zoom-Stufen ausgeblendet werden.

Höhenlinien. Auch dafür gibt es ein [Tutorial](http://blog.thematicmapping.org/2012/07/creating-contour-lines-with-gdal-and.html „http://blog.thematicmapping.org/2012/07/creating-contour-lines-with-gdal-and.html“.)

Interface

Schon früh war klar, dass wir hauptsächlich die Karte und eine Zeitleiste am unteren Rand benötigen würden. Die Zeitleiste besteht dabei aus zwei Bereichen (Micro-Macro-Ansicht) mit denen man im oberen Teil grob einen Bereich auswählen kann und im anderen dann Details sehen kann. Die Auswahl des Zeitraums beeinflusst dabei die Visualisierung.

Später kam uns noch die Idee, dass es hilfreich wäre, wenn man Shapefiles hochladen könnte um die Analyse auf eine bestimmte geografische Region zu beschränken. Mit Hilfe einer Palette am rechten Rand kann man dort Shapefiles erstellen, hochladen oder ein- und ausblenden. Ohne diese Filter-Funktion bezieht sich die Visualisierung immer auf den gesamten Kartenausschnitt.

Aus technischen Gründen haben wir auf eine Suche im finalen Entwurf verzichtet.

Erster Wireframe zum Layout mit Karte, Zeitleiste und Idee zum geteilten Bildschirm zum Vergleichen von zwei Ansichten.

Für die Zeitleiste haben wir uns an der von Google Finance orientiert. [https://www.google.com/finance](https://www.google.com/finance „https://www.google.com/finance“)

Mockup der Anwendung

Letztlich läuft alles darauf hinaus, dass die ausgewählten Daten im gewünschten Format heruntergeladen werden.

Small Multiples

Small Multiples: Wir hielten es für sinnvoll, mehrere Zeitausschnitte miteinander zu vergleichen um so Muster zu erkennen. Auch Abror war von dieser Idee angetan.

Uns kam relativ schnell die Idee, Small Multiples zu verwenden. Abror bekräftigte uns darin, und bat uns auch, sie nicht nur als Karten, sondern auch als Graphen umzusetzen. Er würde gerne beispielsweise die Januarmonate der letzten zehn Jahre vergleichen, um die Auswirkungen des Klimawandels zu kontrollieren.

Es gibt mehrere Möglichkeiten, sich Small Multiples anzuzeigen. Erreichen kann man sie über einen Switch über der Zeitleiste.

Analyse

Normalerweise steht dieser auf »analyze« – man sieht die Karte und die Zeitleiste.

Compare

Stellt man auf »compare« um, wird der gerade ausgewählte Zeitraum mit dem gleichen Zeitraum über die Jahre verglichen. Ist Beispielsweise der Januar 2012 ausgewählt, werden Small Multiples für den Monat Januar über die letzten 10 Jahre generiert.

Dabei lassen sich verschiedene Vergleichszeiträume auswählen. Man könnte statt dem Januar jeden Jahres auch Januardurchschnitt über die Dekaden anzeigen lassen.

So kann man einfach bestimmte Zeitpunkte über die Jahre vergleichen.

Split

»Split« teilt den gerade ausgewählten Zeitraum auf. Wählt man beispielsweise das Jahr 2012 aus und klickt auf »split«, werden einem Small Multiples der einzelnen Monate 2012 angezeigt. Ebenfalls könnte man sich jedoch auch Small Multiples für die Wochen dieses Zeitraumes anzeigen lassen – oder sogar Jahre, falls man mehrere ausgewählt hat.

Außerdem besteht die Möglichkeit, sich die Small Multiples in Form einer Karte oder eines Graphen anzeigen zu lassen. So kann einerseits geprüft werden, ob sich die Lage oder Ausdehnung des Schnees über die Zeit verändert, als auch die absoluten Werte schnell verglichen werden.

Daten

Als wir das erste Mal bei Abror waren, bekamen wir seine Skripte und ein paar Beispieldaten für ein halbes Jahr. Schnell wurde klar, dass die Skripte nicht ohne weiteres bei uns laufen würden, da sie spezielle Software benötigen. Somit konnten wir leider keine eigenen Daten aus Satellitenbildern generieren. Stattdessen arbeiteten wir mit den Beispieldaten, die für einen Prototypen genügten. Diese lagen in einem ASCII-Format vor und bildeten in einem Text-Raster ab wo Schnee liegt und wo nicht. Um damit besser arbeiten zu können, packten wir diese Ja/Nein-Aussagen mit passenden Geo-Koordinaten in eine PostgreSQL-Datenbank.

Scripte von Abror. Die für Windows ausgelegten Programme mussten wir erstmal auf einem Mac reproduzieren. Schließlich scheiterten wir daran, dass ein Algorithmus nur mit einer teuren Geo-Software funktioniert.

Das mit dem gestapelten Graphen in der Zeitleiste ist gar nicht so trivial wie es aussieht.

Aber irgendwie haben wir es dann doch geschafft!

Visualisierung

Mit Hilfe unserer eigenen Tiles und Leaflet brachten wir die Daten auf eine Karte und experimentieren mit verschiedenen Darstellungsformen für den Schnee.

Rechtecke zeigen an, dass Schnee in dem Gebiet liegt. Die Auflösung der Daten beträgt 500 Quadratmeter.

Durchschnittswerte werden über die Transparenz der Rechtecke differenziert. Deckender heißt hierbei: An diesem Ort lag im gewählten Zeitraum häufig Schnee. Es lässt aber keine Rückschlüsse über die Menge des Schnees zu.

Wir haben auch mit anderen Visualisierungsformen experimentiert. Diese schraffierten Linien sind weniger prägnant und zeigen mehr vom Terrain.

Diese Visualisierung schien uns auch geeignet zu sein.

Prototyp

Screencast zum programmierten Prototypen.

Ausblick

Das Gespräch mit Abfror wird zeigen, ob es sich lohnt hier weiterzumachen. Sein Hauptinteresse bestand darin die Daten weltweit verfügbar zu machen, was bisher noch daran gescheitert ist, dass die Skripte nicht funktionieren und User somit keine eigenen Gebiete betrachten können. Im Kern konnten wir aber gut zeigen, dass die starren und unzugänglichen Daten einfach dynamisch visualisiert und navigiert werden können.