RS RainRadar Forecast V0.3
mir geistert die Idee schon ne Weile im Hirn rum, neulich hat‘
s dann klick gemacht: ich musste das mal ausprobieren.
Ausgehend von der „Unwetterzentrale Revolutions“ (welche ich stark abgewandelt schon 2 Jahre im Einsatz habe) aus dem IPS-Forum habe ich mich ans Werk gemacht.
Während die „Unwetterzentrale Revolutions“ in die Vergangenheit schaut (und damit ein Delay von ca. 30 Minuten in Kauf nehmen muss), um daraus Regeninformationen für die Gegenwart zu ermittelt, bietet ein Regenradar-Forecast die Möglichkeit, sehr viel präziser (sowohl zeitlich als auch geographisch) in die Zukunft zu schauen. So die Theorie.
Wetteronline liefert ein animiertes GIF, welches die Regenentwicklung für die kommenden 2 Stunden beinhaltet. Das GIF wird alle 15 Minuten aktualisiert, der Bildintervall im GIF beträgt 15 Minuten. Daraus müssten sich doch für IP-Symcon auswertbare Informationen über möglichen Regen am eigenen Standort generieren lassen, die dann von IP-Symcon weiter verarbeitet werden können. Zum Beispiel, um (bei Abwesenheit) automatisch die Markise einzufahren, Fenster zu schließen..what ever.
Nu isset fertich, das Ganze funktioniert so:
- animiertes Regenradar Forecast-GIF downloaden
- GIF-Animation in Einzelframes zerlegen
- Bildsektor des definierten Standorts auf Regen-Intensitäten hin analysieren
- Analyse-Ergebnisse aufbereiten und
- IPS als digitale Werte zur Weiteren Verwendung zur Verfügung stellen
Selbstverständlich via PHP in der IP-Symcon Umgebung.
Herausgekommen ist ein bischen Visualisierung, viele, viele Variablen mit abgreifbaren Daten.
Bedeutung der gewonnen Daten/Hintergrundinfos
Um mit den Daten richtig umgehen zu können, ist ein detaillierteres Verständnis zum Regenradar selbst und zur Arbeitsweise dieses Projekts notwendig. Denn eigentlich ist es kein Regenradar, sondern eher die Ermittlung des Wassergehalts der unteren Atmosphäre. Aber damit wird ein Otto-Normalverbraucher wiederum nichts anfangen können. Und aus dem Wassergehalt einer Wolke lässt sich nicht zwingend ableiten, ob, wann und wo selbige sich entschließt, sich zu entleeren. Daher will ich auf die meteorologische Einflüsse dieser Stelle gar nicht erst eingehen.
Das Thema Regenradar wird z.B. hier
detailierter und leicht verständlich behandelt.
Unter dem Strich ist es wichtig, zu wissen, dass ein Regenradar keine, über lange Zeit konstanten, exakt vergleichbaren Daten liefert. Vielmehr werden hier sich ständig ändernde Umweltbedingungen in aufwändige Berechnungen einbezogen. Und längst nicht alle Einflüsse sind präzise messbar. Und es sollte auch klar sein, dass sich die Vorhersage-Genauigkeit umgekehrt proportional zur Vorhersagedauer verhält: eine Vorhersage für die kommenden 30 Minuten ist genauer als eine für 2 Stunden.
Das liefert dann Werte, die nahe an der Realität liegen, aber eben nicht immer deckungsgleich. So ist in den letzten Jahren immer wieder zu beobachten, dass im Radarfilm ausgewiesene Regengebiete mit Farbstufe 1 (unterster Intensitätswert) in der Realität und am Boden nicht registrierbar sind. Umgekehrt genau so: besonders bei hochnebelartigem Wetter habe ich leichten Dauerregen erlebt, auf dem Regenradar hingegen weit und breit kein Regenecho. Und das über Stunden.
Fazit: ein Radarecho ist nicht immer zu 100% belastbar.
Wie arbeitet dieses Projekt? Wie funktioniert die Bildanalyse im Detail?
Eigentlich ganz simpel: das runtergeladene, animierte Radar-GIF wird auf der lokalen Festplatte zwischen gespeichert. Anschließend wird das GIF mit Hilfe der integrierten „GIFFrameExtractor“-Klasse in Einzelframes zerlegt.
Nun wird für jedes Frame die Intensitäts-Legende analysiert. Ist die Analyse erfolgreich, werden die ermittelten Farbwerte für jede Regenintensität in ein Array geschrieben. Anschließend wird ein Bildsektor – welcher durch den User vorgegeben wird untersucht. Alle mit dem Intensitätsband übereinstimmenden Farbwerte des untersuchten Bildsektors werden in einem weiteren Array aufintegriert. Pixel für Pixel. Nachdem alle 8 Frames durchgehühnert wurden, werden aus den kumulierten Intensitätswerten Durchschnittswerte – bezogen auf 1 Pixel gebildet. Dieser Wert ist zwar ein Float-Wert, korreliert aber mit den 6 Intensitätsstufen der Farblegende.
Beispiel: Intensitätswert 2,9 liegt dicht an der Intensitätsstufe 3 (von links gezählt) in der Farblegende des Radarbilds.
Da der Forecast möglichst für den eigenen Standort und nicht für eine Region ermittelt werden soll, sollte auch der zu analysierende Bildsektor so klein wie möglich gehalten werden. Ich empfehle einen Radius von 1 Pixel. Das ergibt einen Bildsektor von 3×3 Pixel. Das ergibt eine Fäche von 3x3km in der Realität. Es kommt also darauf an, den eigenen Standort so präzise wie möglich anzugeben. Aus diesen 3×3 Pixeln wird dann der durchschnittliche Intensitätswert für 1 Pixel ermittelt. Das hat den Vorteil, dass sowohl leichte Ungenauigkeiten in der Sektor-Positionierung als auch oben beschriebene Probleme in der Belastbarkeit der Radarechos besser interpretiert werden können: ein ermittelter Intensitätsdurchschnitt von 0,6 (statt 1) lässt den Schluss zu, dass es -trotz Radarecho – eher nicht regnen wird. Aber hier muss jeder seine eigenen Erfahrungen sammeln.
Genau aus diesem Grunde verzichte ich derzeit auch auf eigene Reaktionen innerhalb dieses Projekts auf die gewonnenen Informationen. Vielleicht entwickelt sich aber hier noch Potenzial => ich bin gespannt auf die Feedbacks ;-)
Live-Daten: Eine Gegenüberstellung der Forecast-Werte und der lokal gemessenen Niederschlagswerte findet man hier.
Beispiel: Auswerte-Ergebnis mit verschiedenen Schwellwert-Einstellungen, darunter eine Gegenüberstellung der Forecast-Daten mit gemessenen Ist-Daten:
erste Erfahrungen
Da mir ausgewogene Projekte wichtig sind, habe ich nicht nur Licht-, sondern auch Schattenseiten eingebaut.
Nach ersten Tests sehen die Ergebnisse überraschend gut aus. Im Bild ein Vergleich der 60Minuten-Forecast-Daten mit echten, am Standort gemessenen Niederschlagsdaten. Diese Gegenüberstellung gibts täglich, Live und in Farbe in meinem Area51-Bereich: Link
Oben habe ich empfohlen, den Standort-Radius möglichst klein zu halten. Das hat dummerweise einen Nachteil: ziehen (kleine) Regengebiete zu schnell durch den Standort-Sektor, werden diese u.U. nicht erfasst, weil die zeitliche Auflösung nicht ausreicht: im ersten Frame liegt das Regengebiet noch vor dem Standort-Sektor, im nächsten Frame liegt es dahinter. Es ist quasi in den 15 Minuten zwischen den Frames über den Standort „drüber gehüpft“.
Ein ähnliches Problem stellt die „Empfindlichkeit“ des Regenradars dar: obwohl eine Intensitätsstufe 1 vorhergesagt wird, muss es noch lange nicht regnen (bzw. Regen auf der Erdoberfläche ankommen). Umgekehrt genau so. Ich habe daher bei mir aktuell den Intensitäts-Schwellwert auf 1,1 eingestellt: erst wenn dieser Wert für meinen Standort erreicht/überschritten ist, schlägt die Auswertelogik Alarm.
Hier muss man sich die Frage stellen: will ich eine Warnung, wenn es mit hoher Wahrscheinlichkeit regnen wird (=> hohe Trefferquote ) oder will ich eine Warnung ob es evtl. regnet (=> hohe Sicherheit vor Regen)? Im ersten Fall sollte man den Schwellwert >=1 setzen, im letzten Fall eher <=1.
Ich denke, hier muss man einfach Erfahrungen sammeln und sich überlegen, wie man damit umgeht.
Projekt-Homepage
Und wer jetzt auch noch Lust bekommen hat, das Projekt selbst ausprobieren zu wollen: hier gibt’s reichlich Text zur Abschreckung und auch einen Download ;-)
