BrightSkyPlus

Welche gesellschaftliche Herausforderung adressiert euer Prototyp?

Der Deutsche Wetterdienst stellt den Großteil seiner erhobenen Wetterdaten zwar frei, aber in überwiegend unüblichen und schwer auslesbaren Datenformaten zur Verfügung. Diese Daten werden unter öffentlicher Finanzierung erhoben, sind aber für die Öffentlichkeit schwer nutzbar. In der Praxis bedeutet dies, dass Entwickler*innen entweder auf kommerzielle Alternativen zurückgreifen oder erheblichen Aufwand betreiben müssen, um in ihren Anwendungen Wetterdaten zu verwenden. Für kommerzielle Anwendungen (Wetterapps, etc.) müssen die hierbei anfallenden Kosten auf genau diese Anwender*innen umgelegt werden, die die ursprüngliche Erhebung von Wetterdaten schon mit finanziert haben. Für gesellschaftliche Anwendungen wie z.B. der Korrelation von Verkehrsunfall- mit Wetterdaten bei Code für Münster führt die hohe Einstiegshürde im besten Fall zu einer Verzögerung, im schlimmsten zur Nichtdurchführung des Projekts. Bright Sky ist ein Service, der diese erhobenen Daten des Deutschen Wetterdienst verständlich und sofort einsatzfähig aufbereitet und zur Verfügung stellt. Die hohen Nutzungszahlen von Bright Sky und das Feedback in Issues und Emails zeigen, dass das Projekt eine beliebte Anwendung ist. Dennoch verbleiben einige Felder, in denen Bright Sky bisher keinen einfachen Zugang zu Daten des Deutschen Wetterdienstes  bietet, und in denen die Nutzer*innen weiterhin vor obiger Problematik stehen. Bright Sky ist ein im Rahmen der siebten Runde des Prototype Fund entstandener Service. Ziel dieses Projektes ist die Erweiterung um neue Features und Datensätze, die im ersten Förderungszeitraum nicht berücksichtigt werden konnten, seitdem aber regelmäßig aus der Community angefragt werden.

Wie geht ihr das Problem an?

Bright Sky besteht aus vier Komponenten, die hauptsächlich auf Python und Postgres basieren. Die erste Komponente, das Polling, soll minütliche den DWD Server Abfragen und soll mit Python, Redis und Requests gebaut werden. Die zweite Komponente, das Parsing, also Auslesen, Transformieren, Zusammenführen der Wetterparameter soll ebenfalls über Python, Parsel, Requests realisiert werden. Die dritte Kompenente, der Storage soll die Struktur, Speicherung der Wetterdaten mit Postgres angehen. Zum Schluss die API: die Auslieferung der Wetterdaten über anwendungsnah gestaltete Schnittstellen soll über Python und Falcon gebaut werden. Der Umfang von Eingriffen in diese Komponenten variiert für die drei Arten geplanter Erweiterungen. Das Hinzufügen neuer Wetterparameter erfordert lediglich kleine Anpassungen im Polling und im Parser. Zum Beispiel angepasste URLs vom DWD Open Data Server und neue Parser für zum Beipsiel UV-Index sowie minimale Anpassungen in der Datenbank und API. Gebietsorientierte Daten wie Radardaten und Unwetterwarnungen benötigen größere Restrukturierungen der Datenbankstruktur, die derzeit stark auf stationsbasierte Daten ausgelegt ist. Hinzu kommt die Erstellung neuer Parser für RADOLAN, für JSON-Dateien mit Warnungen und API-Schittstellen. Zuletzt können die statistischen Auswertungen (Tageszusammenfassungen) vollständig in der API erledigt werden und erfordern keine Anpassung der anderen Komponenten.

An wen richtet sich euer Tool?

Bright Sky richtet sich an Programmierer*innen sowohl aus dem Hobby- und Open-Source- als auch aus dem kommerziellen sowie wissenschaftlichen Bereich, die Wetterdaten benötigen. Ein besonders interessanter Unterbereich sind die Anwender*innen aus der Civic Science, wie z.B. die diversen Untergruppen von Code for Germany. Mehrfach haben mich aber auch schon E-Mails aus Forschungseinrichtungen und von Firmen erreicht, die Wetterdaten aus Bright Sky nutzen.