Offen zugänglich - und trotzdem kein Selbstläufer

Bei Schweden hatte ich zunächst den Eindruck, dass die Integration sehr unkompliziert wird. SMHI stellt die Messdaten offen bereit, ohne Registrierung oder API-Key. Das ist wirklich angenehm: Über den MetObs-Katalog kann ich nachvollziehbar von den Parametern zu Stationen, Zeiträumen und einzelnen Dateien gehen.

Offizielle Monatswerte gibt es nur für Temperaturmittel und Niederschlag. Das hilft, aber es sind eben nur zwei Werte. Für Maximum, Minimum, Sonnenschein, Temperaturtage und Gewittertage muss ich weiterhin selbst aus Tages- oder Stundendaten rechnen - genau das, was bei anderen Ländern schon viel zusätzliche Logik erzeugt hat.

Nicht jede Wetterstation misst dieselben Dinge. In der Stationsliste hat jede Station deshalb mehrere Kennziffern, je nachdem, ob dort zum Beispiel Temperatur, Niederschlag oder Sonnenstunden gemessen werden. Diese Kennziffern muss ich zuerst auseinanderhalten und den passenden Daten zuordnen.

Für die verschiedenen Messwerte müssen dann Daten von unterschiedlichen Stationen zusammenkommen. Das ist wichtig, weil sonst leicht der Eindruck entsteht, die Daten seien überall gleich gut verteilt. Tatsächlich gibt es je nach Messwert unterschiedlich viele Stationen.

Die Umsetzung im Mapper trennt diese Daten bewusst nach ihrem fachlichen Ursprung. Parameter 22 liefert Temperaturmittel und Parameter 23 Niederschlag direkt als offizielle Monatswerte. Aus den Tagesextremen von Parameter 20 und 19 werden Temperaturmaximum, Temperaturminimum sowie Sommer-, Tropen-, Frost- und Eistage nur dann berechnet, wenn alle Tage eines Monats vorhanden sind.

Die stündlichen Sonnenwerte aus Parameter 10 werden erst zu vollständigen Tagen und dann zu Monaten summiert. Für Gewittertage nutze ich Parameter 13; die genaue Regel dazu beschreibe ich im nächsten Abschnitt.

Positiv finde ich die Qualitätsangaben von SMHI. Grüne Werte sind kontrolliert, gelbe Werte dürfen aber nicht pauschal verworfen werden: Bei den Monatswerten und Tagesextremen können sie offizielle aggregierte Werte bedeuten. Der Mapper übernimmt deshalb G und Y, behandelt fehlende oder verworfene Werte aber nicht als null.

Neuschnee integriere ich nicht. SMHI liefert Schneehöhe, aber Schneehöhe ist kein Neuschnee. Eine Differenz zwischen zwei Schneehöhen wäre wegen Schmelze oder Verwehung fachlich irreführend. Mir ist eine offen bleibende Metrik hier lieber als eine scheinbar vollständige, aber falsche Zahl.

Auch die Sprache war für mich wieder einmal ein zusätzlicher Rechercheaufwand. Die SMHI-Feldnamen, Parameterbeschreibungen und Qualitätshinweise sind auf Schwedisch. Begriffe wie aktuelles Wetter, repräsentativer Monat oder Qualität musste ich zuerst sicher einordnen, bevor ich sie fachlich korrekt zuordnen konnte.

Beim Herunterladen gab es außerdem technische Stolpersteine. Die CSV-Dateien beginnen je nach Messwert mit unterschiedlichen Kopfbereichen: Zuerst stehen Angaben zur Station und zum Zeitraum, erst danach folgen die eigentlichen Messwerte. Auch die Zeitspalten sind nicht einheitlich. Monats- und Tagesdaten verwenden Zeitintervalle, Sonnenstunden und Wetterbeobachtungen dagegen getrennte Datums- und Uhrzeitspalten.

Zusätzlich meldet SMHI manche CSV-Dateien technisch als text/plain statt als CSV. Der Downloader muss diese Varianten trotzdem als Datendateien erkennen, sonst würden vorhandene Messwerte fälschlich übersprungen. Das ist kein Fehler bei SMHI, macht einen allgemeinen Import aber aufwendiger.

Die beiden Zeiträume corrected-archive und latest-months bringen einen weiteren Kompromiss mit sich. Das Archiv enthält die qualitätskontrollierte Historie, endet aber vor den neuesten Monaten. latest-months schließt diese Lücke, ist aber nur vorläufig. Ich führe beides zusammen, lasse bei Überschneidungen jedoch immer corrected-archive gewinnen. So bleiben neue Daten sichtbar, ohne dass vorläufige Werte endgültige Archivwerte überschreiben.

Außerdem soll der historische Massendownload nur nacheinander erfolgen. Gerade die vielen Stundenwerte für Sonnenschein machen den ersten Import langsam. Das ist verständlich und fair gegenüber der Quelle, aber für die Verarbeitung weniger bequem. Beim praktischen Herunterladen empfinde ich Schweden trotz der großen Datenmenge trotzdem als angenehm schnell. SMHI setzt für diesen Abruf keine engen Anfragelimits oder API-Schlüssel-Hürden ein. Dadurch kann ich die Dateien ohne künstliche Wartezeiten laden.

Beim Import im Klimadaten-Mapper bin ich dagegen an eine harte Speichergrenze gestoßen.
Der SE-Bestand umfasst mehrere tausend SMHI-CSV-Dateien; zusammengenommen liegt das in der Größenordnung von rund 50 bis 80 Millionen Datenzeilen. Besonders schwer wiegen die Stunden- und Wetterarchive, in denen einzelne Dateien bereits Hunderttausende Zeilen haben. Solange der Mapper alle diese Rohzeilen erst vollständig einliest und erst danach verdichtet, werden Dutzende Millionen Beobachtungen gleichzeitig im Speicher gehalten - das führte trotz 128GB Arbeitsspeicher, immer wieder zu abstürzen, sodass ich die gesamte Reihe nie in einem Rutsch fertig bekam.

Die Lösung war eine Extrawurst für Schweden, ein Streaming-Import: Jede Datei wird sofort verdichtet und danach verworfen, statt den gesamten Bestand auf einmal vorzuhalten. Velleicht hilft mir das Prinzip später auch bei anderen Ländern, denn vor allem die Stundenwerte sind zum Teil gigantisch und war jetzt erstmal bei Schweden nötig.

Mein Fazit ist gemischt: Die offene, gut dokumentierte SMHI-Quelle und die offiziellen Monatswerte sind eine sehr gute Grundlage. Gleichzeitig verlangen die getrennten Messnetze, die unterschiedlichen Formate, zusätzlich unterschiedliche Header zum Teil je Metrik, die begrenzte Gewitterbeobachtung einen vorsichtigen Umgang mit der Abdeckung. Schweden war grundsätzlich gut integrierbar, aber es kam immer wieder zu kleineren, wie ich finde unnötigen Hürden, sodass ich trotz dieser kleineren Hürden meinen Mapper und Downloader relativ stark an Schweden anpassen musste