Documentation

The meteocool technical documentation is currently only available in German! Sorry.

You can help by translating it on Github.

Inhaltsverzeichnis

1 Anwendungsfälle

1.1 Regen-Radar

Die zentrale Funktionalität von meteocool besteht in der Visualisierung von wetterbezogenen Daten. Dabei liegt der Fokus auf mobilen Endgeräten und einer darauf optimierten Oberfläche. Insbesondere zeigt die Anwendung asynchron eintreffende Daten (Radardaten, Blitze, andere Ereignisse) ohne ein "neuladen" der Seite an.

1.2 Vorab-Benachrichtigungen

Die bei der Verarbeitung der Wetterdaten anfallenden Artefakte werden genutzt, um relativ genaue, kurzfristige und lokale Benachrichtigungen über Wetterumschwünge an mobile Endgeräte zuzustellen.

Besonders bei sich kurzfristig entwickelnden Tiefdrucklagen (Sommergewittern) können derartige Informationen nicht dem normalen Wetterbericht entnommen werden.

2 Architektur

Die Verarbeitung und Speicherung von Wetter- und Nutzerdaten aus asynchronen Quellen bedarf einer Kombination aus verschiedenen Diensten und Softwaresystemen. Die Umsetzung erfolgt daher in Form von Microservices. Diese erleichtern den administrativen Umgang gegenüber monolithischen Systemen stark. Ebenfalls können so z.B. Anforderungen an die Verfügbarkeit leichter umgesetzt werden (siehe 4.2).

Im Vordergrund steht die Verarbeitung von Radardaten. Auf den daraus resultierenden Artefakten basieren die meisten Funktionen der Plattform.

2.1 Verarbeitung von Radardaten

PIC
Abbildung 1:Radarverbund des DWD mit Abdeckung; Bildquelle: © DWD

Die Radardaten werden ca. alle 5 Minuten durch den Deutschen Wetterdienst zur Verfügung gestellt und besitzen eine räumliche Auflösung von 1x1 km pro Pixel. [1]

meteocool verarbeitet bereits die sogenannte composite-Variante der Radardaten. In dieser vorverarbeiteten Version wurden bereits die Aufnahmen aller Stationen im Radarverbund zu einem nationalen Gitter kombiniert. Im vom DWD für diesen Zweck definierten Run-Length-Encoding-Verfahren sind für diesen Wert 8 Bit pro Pixel vorgesehen. [2]

Die Regen-Intensitäten liegen pro Pixel in einer eigens vom DWD definierten Einheit “RVP6” vor. Vor der Weiterverarbeitung werden die Werte in die gebräuchlichere Einheit dbZ (Dämpfung relativ zum Faktor Z; logarithmische Skala, dimensionslos [3]).

Die Radardaten werden automatisch vom DWD Opendata FTP Server abgeholt und mit dem abhängigkeitsbasierten Build-System GNU Make und diversen Python-Skripten durch die im Folgenden beschriebenen Verarbeitungsschritte transformiert.

Geographische Projektionen

Da die Erde eine Kugel ist, ist zur korrekten Darstellung ebendieser auf einer zweidiemensionalen Karte eine mathematische Projektion notwendig. In der Geographie gibt es eine Vielzahl an gebräuchlichen Projektionen mit unterschiedlichen Eigenschaften:

  • Plate Carree (ESRI:53001): zylindrische Projektion, welche die Erdoberfläche in Rechtecke mit parallel verlaufenden Kanten einteilt. Zu Navigations- oder Referenzzwecken ist sie aufgrund ihrer ungenauigkeit ungeeignet. Sie wird oft zur Visualisierung globaler Daten verwendet. [?]
  • Mollweide-Projektion (ESRI:54009): flächentreue Projektion, Darstellung als Ellipse. Breitenkreise stellen parallel Linien dar, Meridiane werden (bis auf den Mittelmeridian) als Ellipse dargestellt. [?]
  • Web Mercator Projektion (EPSG:3857): Spezialfall der Mercator-Projektion, einer zylindrischen Projektion, die in der Nähe des Equators relativ genau ist (d.h. keine/sehr geringe Winkelverzerrung vorweist).
    Dies führt z.B. dazu, dass der Afrikanische Kontinent genau so groß erscheint wie der Inselstaat Island.

    Diese Projektion wird von sogut wie allen Karten- und Navigationsdiensten für Endnutzer verwendet. Sie wird umgangssprachlich auch als Google Projektion bezeichnet. [?]

PIC

Von links: Plate Carree, Mollweide, Web Mercator; Bildquelle Wikipedia (CC BY-SA 3.0)

Jede Projektion wird im GIS-Jargon mit eine sog. EPSG-Nummer oder ESRI-Nummer identifiziert. Dies erleichtert das Arbeiten bzw. Konvertieren zwischen Projektionen, da sich hinter jeder EPSG-Nummer eine Vielzahl an mathematischen Parametern verbirgt, die zur Definition des jeweiligen Koordinatensystems notwendig sind.

2.1.1 Visualisierung

Um die Radardaten auf einer zwei-dimensionalen Karte verständlich darzustellen, müssen die Daten im Sinne einer dritten Dimension visualisiert werden. Dazu wurde zunächst ein einfaches Verfahren gewählt, welches die Intensitäten zwischen 0 dbZ (Annahme: kein Regen) und 65 dbZ (extremer Starkregen/Hagel) farblich kodiert.

Um bei einer zukünftigen Erhöhung der derzeit 256 Intensitäts-Stufen flexibel reagieren zu können, wurde, anstatt einer statischen Palette, ein linearer Farbverlauf innerhalb jeder der acht Farbstufen der Skala implementiert:

Die Grundfarben werden im RGB-Farbformat angegeben. Ein Python-Script konvertiert diese ins HSL-Farbmodell und schwächt die L-Komponente (Lightness) nach rechts hin ab.

Dem Betrachter soll der dunklere Farbton eine höhere Sturmintensität signalisieren.


PIC

Abbildung 2: Aus Grundfarben generierte Legende

2.1.2 Geo-Referencing
PIC
Abbildung 3: Radardaten nach Einfärbung, vor der Georeferenzierung

Das Radarkomposit liegt nun als mehrkanaliges Rasterbild (3) in der vom DWD vorgegebenen Auflösung von 1100x900 km (= Pixel) vor. Das Radarbild muss nun in eine einheitliche Projektion überführt werden, so dass es ohne Verzerrungen über vorhandenes Kartenmaterial gelegt werden kann. Da das Kartenmaterial von OpenStreetMap in der Web Mercator Projektion [4] vorliegt, sollen die Radardaten ebenfalls in diese Projektion umgewandelt werden.

Nachdem die Projektion mit einem Tool aus der GDAL-Bibliothek zu Web Mercator geändert wurde, muss das resultierende Bild zudem noch an einem Referenzpunkt in einem globalen Koordinatensystem angehängt werden. Besagte Eckpunkte liefert der DWD in seiner offiziellen Dokumentation. [5]

Zur flexiblen, endgeräteunabhängigen Auslieferung der Bilddaten werden die Radardaten schließlich in das Container-Format .mbtiles verpackt, welche eine Aufteilung der Radardaten in einzelne Kacheln in verschiedenen Auflösungen (Zoom-Stufen) vorsieht. [6]

2.1.3 Nowcast-Daten

Neben den aktuellen Radardaten stellt der DWD auch alle 5 Minuten einen sogenannten Nowcast bereit. Dabei handelt es sich um zeitlich interpolierte Satellitenbilder (im gleichen Format wie im vorherigen Schritt behandelte “live” Radarbild). Nowcast-Vorhersagen sind zeitlich meist auf wenige Stunden begrenzt, besitzen allerdings eine wesentlich höhere Genauigkeit als globale Wettermodelle, die (aufgrund ihrer Komplexität) nur alle 3-12 Stunden neu berechnet werden. [9]

Die Integration dieser Vorhersage ermöglicht dem Benutzer der App die Bestimmung von Zugrichtung und Abregenverhalten von Regenwolken und Gewittern. Sie basieren auf Windrichtung, Luftdruck und anderen lokalen Messungen, welche örtlich vom DWD vorgenommen und verarbeitet werden.

Die Vorhersagen liegen in einem kleineren Gitter von 900x900 km in 24 Dateien vor (d.h. bis zu 120 Minuten akkurater Vorhersagen). Die Verarbeitung verläuft analog zu den in 2.1.2 erläuterten Radardaten.

2.2 Vorab-Benachrichtigungen

Wurden relativ früh im Entwicklungsprozess sog. Push-Benachrichtigungen (siehe Punkt 3) implementiert.

Die zugrundeliegende Idee ist, dass die mobile Anwendung im Hintergrund eine grobe, aktuelle Position des jeweiligen Nutzers anonym an den meteocool-Server übermittelt. Bei der darauffolgenden, regelmäßigen Verarbeitung neuer Nowcast-Daten (wie in 2.1.3 beschrieben), werden die Vorhersagen anhand der zuvor übermittelten Positionen auf Regen überprüft.


PIC

Abbildung 4: Kontrollfluss bei der Zustellung von Push-Benachrichtigungen

Technisch betrachtet lässt sich das 900x900 km Gitter als dreidimensionales Array betrachten. Um die vorhergesagte Intensität an einer GPS-Koordinate bestimmen zu können, müssen die GPS-Koordinaten vom Latitude/Longitude-Format (WSG84) in ein x- und y-Index umgerechnet werden. Danach kann der Zugriff auf die dritte Dimension (Regenintensität) erfolgen.

Verschiedene Parameter der Benachrichtung sind per REST-API konfigurierbar. Dazu gehören unter anderen:

Neben den über die API konfigurierbaren Parametern nimmt der Server diverse Optimierungen bezüglich des Benachrichtigungsverhaltens vor. Der Hintergrund dabei ist, dass Smartphone-Benutzer Apps mit übermäßig vielen (irrelevanten) Push-Benachrichtigungen schnell wieder de-installieren. In einer Beta-Testphase wurden folgende Probleme identifiziert:

  1. Wenn der Benutzer sich schnell durch eine Regenfront bewegt (z.B. Auto oder Zug) meldet sein Smartphone des Öfteren einen neuen Standort (Punkt auf der Strecke), für den der Nutzer einige Minuten später benachrichtigt wird.

    Dies kann ggf. dazu führen, dass sich eine Menge an Benachrichtungen auf dem Bildschirm des Smartphones ansammeln, die für den reisenden Nutzer nicht relevant sind.

    Punkt 2.2.1

  2. Bei kurzen Schauern kann es sein, dass der Nutzer nichts vom Gewitter mitbekommt, z.B. weil er sich in einem Gebäude aufhält (vor allem nachts). In diesem Fall interessieren ihn die Benachrichtungen nicht, wenn es bereits wieder aufgehört hat zu regnen.

    Punkt 2.2.2

  3. Vor allem unterwegs kann man aus Gründen der Verkehrssicherheit sein Handy nicht immer benutzen, um die Satellitenbilder einzusehen.

    Punkt 2.2.3

2.2.1 Reisemodus

Um dem Benutzer keine Benachrichtungen zuzustellen, solange er sich schneller als eine gewisse Geschwindigkeit bewegt (aktuell 25 km/h), ist es notwendig, serverseitig zu erkennen, ob sich der Benutzer fortbewegt.

Dazu gibt es verschiedene Möglichkeiten. Die einfachste besteht darin, die Daten der IMU (Intertial Measurement Unit) des Smartphones auszulesen. Da diese aber, besonders im geringen Geschwindigkeitsbereich, oft ungenau ist, wurde entschieden, diesen zunächst nicht in die Berechnung der Benutzergeschwindigkeit aufzunehmen.

Eine zuverlässigere Aussage über die Geschwindgkeit des Benutzers lässt sich über die letzten zwei GPS-Koordinaten und entsprechende Zeitstempel berechnen. Um zu keinem Zeitpunkt mehr als eine Position pro Nutzer speichern zu müssen (Datenschutz bzw. -sparsamkeit laut DSGVO [11]) wird die aktuelle Geschwindigkeit zum Zeitpunkt der Übermittlung des neuen Standorts neu berechnet.

Dazu wird die Luftlinie zwischen der alten und der neuen Koordinate auf der Oberfläche einer Kugel berechnet und durch die Zeitdifferenz der zwei Ortsangaben geteilt. Es ergibt sich die Geschwindigkeit in km/h, welche mit in der Datenbank gespeichert wird.

Die Backend-Komponente, welche die Push-Benachrichtungen versendet, prüft bei der nächsten Verarbeitung von Radardaten, ob der Wert unterhalb eines besitmmten Grenzwerts (25 km/h) liegt. Zuvor wird noch ein Wert von der gespeicherten Geschwindigkeit abgezogen, der von der seit dem letzten Update verstrichenen Zeit und der zuvor berechneten Geschwindigkeit abhängt (sog. cool-off -Funktion).

2.2.2 Aktualität von Benachrichtigungen

Um das Usability-Problem der veralteten Benachrichtigungen zu beheben, wurden sog. silent- bzw. data pushes implementiert.

Diese werden vom Backend an ein Client-Gerät gesendet, sobald das Gewitter, für das zuvor eine Push-Nachricht gesendet wurde, wieder abgezogen ist. Mittels APNS bzw. Google Firebase wird auf dem Client-Gerät ein Teilprogramm ausgeführt, welches alle aktuell auf dem Display angezeigten Benachrichtigungen löscht und eine Information darüber an das Backend sendet.

PIC
Abbildung 5: Von links: Push-Benachrichtigung im gesperrten Zustand, Push-Benachrichtigung nach force touch

Die Information darüber, ob es aufgehört hat zu regnen, wird dem aktuellen Radarbild alle 5 Minuten entnommen.

2.2.3 Generierung von Vorschaubildern

Um die mit dem Smartphone notwendige Interaktion gering zu halten, wurden in der iOS App sog. Media Attachments implementiert. So ist es möglich, neben einer sonst rein textuellen Benachrichtigung auch Bilder (u.a.) auf dem Display anzuzeigen.

Auf modernen iOS-Geräten (iPhone 6S und aufwärts) besteht zudem die Möglichkeit auch im gesperrten Zustand durch die sog. force touch-Geste einen bildschirmfüllende Kartenausschnitt anzuzeigen.

2.3 Backend

Neben der zuvor beschriebenen Wetterdaten- und Push-Komponente (zusammengefasst zum dwd-Container) verwaltet der app-Container alle Interaktionen mit Endgeräten. Zur persistenten Speicherung und als Interface zur Push-Komponente dient eine Instanz der Key-Value-Store-Datenbank “MongoDB”.

2.3.1 Öffentliche REST API

Die von den Endgeräten initierte Kommunikation mit dem Backend wird über eine REST-basierte HTTP API abgehandelt.

Endgeräte identifizieren sich gegenüber dem Server anhand eines Tokens. Dieses Token generiert das mobile Betriebssystem beim ersten Start der App. Es dient gleichzeitig der Identifizierung gegenüber der API für Push-Benachrichtigungen von Apple bzw. Google.

Das Token ist insofern nicht sicherheitsrelevant, als dass anhand des Tokens keine Informationen über das Gerät, den Nutzer oder seinen Standort abgefragt werden können.

2.4 Tileserver

Um die in Kapitel 2.1.1 generierten mbtiles-Archivdateien über eine einheitliche API anzubieten kommt ein sog. Tileserver zum einsatz. Tileserver sind Softwarekomponenten, die Kartematerial über eine Netzwerkschnittstelle zur Verfügung stellen. Gebräuchliche Schnittstellen wie WTMS (XML-basiert) und GeoJSON (JavaScript Object Notation) ermöglichen es so Bilddaten kachelbasiert (partiell) abrufen zu können.

Es existieren verschiedene freie Tileserver-Implementierungen. Sie unterscheiden sich hauptsächlich im Technologie-Stack, auf dem sie basieren. meteocool verwendet hierzu die in Node.js implementierte Software tileserver-gl, da die Schnittstelle zum in 2.1 beschriebenen dwd-Container am einfachen realisierbar war.

2.5 Frontend

Die plattformübergreifende, HTML5-basierte Web-Oberfläche basiert auf dem Mapping-Framework OpenLayers. OpenLayers ist ein in JavaScript geschriebenes Framework, um Kartenmaterial flexibel und über diverse Anbindungen (Backends) im Browser darzustellen. Eine der wichtigsten Abstraktionen von OpenLayers besteht in der Übereinanderlagerung von sog. Layern. So ist es z.B. mit geringem Aufwand möglich, mehrere Layer aus verschiedenen Quellen geographisch korrekt übereinanderzulegen und mit ihnen zu interagieren.

Auf ein komplexes GUI-Framework (Angular, Vue, etc.) wurde verzichtet, da die App fast ausschließlich aus der Kartenansicht besteht.

Zur Interaktion mit dem Backend baut der Browser nach dem Aufruf der meteocool-Startseite eine WebSockets-Verbindung zum Backend hin auf. Über diese Verbindung werden asynchron durch das Backend ausgelöste Informationen an die Clients übertragen, u.a.:

Desweiteren verwendet die Oberfläche die Google Workbox Bibliothek, um meteocool so zu einer sogenannten Progressive Web App (PWA) zu machen. Durch die Verwendung von modernen Webtechnologien wie Service Workers und Local Storage wird auf diese Weise die Geschwindigkeit sowie die Resilienz gegenüber (kurzzeitigen) Ausfällen der Netzwerkverbindung erhöht und die Verwendung von mobilen Daten reduziert.

3 Mobile Anwendungen

Durch die beschriebenen Optimierungen an der HTML5-Oberfläche kann sie nun als Grundlage für eine “native” Anwendung verwendet werden.

Für die zwei populärsten mobilen Betriebssysteme, iOS und Android, wurde jeweils eine App entwickelt. Dies ist notwendig, um nativ vom Betriebssytem bereitgestellte Schnittstellen wie Background Location und Push-Benachrichtigungen nutzen zu können. Für reine Web-Apps stehen diese Funktionalitäten nicht zur Verfügung.

4 Referenzen