Gut strukturiert - aber nur in kleinen Portionen

Spanien war jetzt noch nicht direkt geplant, aber auf einen Schlag einen großen unbefüllten Fleck auf der Karte füllen zu können motivierte doch sehr.

Die ersten Recherchen ergaben, dass die Einbindung über die API relativ einfach und gut dokumentiert ist.
AEMET hat ein OpenData Portal und man konnte sich direkt reinhängen. Die Daten sind ordentlich strukturiert, doch API-Keys, zweistufige Abrufe, kleine Zeitfenster und eine enge Rategrenze machten aus dem historischen Import vor allem eine Frage der Zeit.

Der erste Eindruck

Eine dokumentierte API - das klang zunächst einfach

Für Spanien wollte ich die Wetter- und Klimadaten über den offenen Datendienst von AEMET in die Klimachronik holen. Auf den ersten Blick sah das erfreulich unkompliziert aus, da alles vorhanden war: Es gibt eine dokumentierte REST-API, Stationskennungen und monatliche Klimawerte. Genau die Art von Datenangebot, bei der ich zunächst davon ausgehe, dass sich ein Land vergleichsweise direkt anbinden lässt.

Die eigentliche Implementierung war dann auch nicht das Problem. Schwieriger waren der Zugang und vor allem das zähe Tempo, mit dem sich ein historischer Bestand über ~900 Wetterstationen aufbauen lässt. Aus einer grundsätzlich gut strukturierten Quelle wurde dadurch ein Export, der für historische Daten wenig geeinget war, da es es nur stückchenweise voran ging.
Ich habe durchaus nach anderen Optionen gesucht an die Daten zu kommen, aber es scheint nur die API mit den moantlihcen Werten zu geben.

Zugang und API-Struktur

Jeder Datensatz beginnt mit einem Schlüssel und einem Umweg

Ohne registrierten API-Key geht bei AEMET OpenData fast nichts. Ich musste mich beim Dienst anmelden, einen persönlichen Schlüssel beantragen und diesen bei den Anfragen mitsenden. Die API arbeitet dabei zweistufig: Die erste Antwort enthält zunächst nur einen Verweis auf eine zweite URL. Erst dort liegen die eigentlichen Monatsdaten. Technisch ist das sauber gelöst, für einen großen historischen Abruf bedeutet es aber praktisch zwei Abrufe pro Datenfenster. Einen großen Sammeldownload für alle Stationen und Jahre konnte ich für diese Reihe nicht finden; die Daten mussten deshalb stations- und zeitraumweise abgefragt werden. AEMET OpenData war dabei meine eigentliche Datenquelle, während die API-Dokumentation den technischen Ablauf vorgab.

Die nächste Grenze steckt direkt im Zeitraum einer Anfrage: Ein einzelner Request darf höchstens 36 Monate umfassen. Für lange historische Wetterreihen musste ich die Abfragen deshalb in Dreijahresfenster zerlegen, leere Zeiträume überspringen und die einzelnen Teile anschließend wieder zusammenführen.

Zusätzlich liefert mir das Stationsinventar kein Startjahr für die jeweilige Station. Ob eine Station beispielsweise sehr früh oder erst deutlich später beginnt, zeigt sich erst beim Abruf. Statt dann für jede Station blind vom Jahr 1700 an Fenster für Fenster abzufragen, suche ich deshalb zunächst exponentiell gezielt nach dem frühesten Zeitraum, in dem tatsächlich Daten vorhanden sind.

Bei etwas über 900 Stationen summieren sich kleine technische Umwege schnell. Entscheidend war deshalb nicht nur, Daten abrufen zu können, sondern möglichst wenig leere oder unnötige Anfragen zu erzeugen.

Die eigentliche Bremse

40 Requests pro Minute - und viele API-Keys

AEMET begrenzt die Abrufe auf 40 Requests pro Minute und pro Key.

Für den laufenden Betrieb wo ich dann nur mehr wenige Monate hole wäre das kein großes Problem.
Für einen einmaligen historischen Aufbau mit etwas über 900 Stationen, Dreijahresfenstern, Startjahrsuche und dem zweistufigen Abruf aus Verweis und eigentlichen Daten wird diese Grenze jedoch schnell zum bestimmenden Faktor.

Mit einem einzelnen Schlüssel hätte sich der Download des kompletten historische Bestand über viele Tage gezogen. Deshalb habe ich 8 API-Keys parallel eingesetzt. AEMET OpenData blieb dabei für jeden einzelnen Schlüssel auf die vorgegebene Grenze von 40 Requests pro Minute beschränkt.

In Summe waren damit theoretisch bis zu 320 Abrufe pro Minute möglich.
Das war meine pragmatische Lösung, um den historischen Bestand einmalig in einer vertretbaren Größenordnung aufzubauen.

Mir ist bewusst, dass der Einsatz mehrerer Schlüssel wie eine Umgehung der Rategrenze wirken kann. Mein Ziel war jedoch nicht, den Dienst dauerhaft stark zu belasten oder die Daten kommerziell massenhaft abzugreifen, sondern den historischen Bestand für die Klimachronik einmal vollständig zusammenzuführen. Sobald dieser Grundbestand steht, sind für neue Jahre nur noch kleine Nachzüge nötig.

Sprache und aktueller Stand

Ein paar zusätzliche Übersetzungsschritte - aber die Daten sind online

Abseits der technischen Limits war für mich vor allem die Sprache wieder ein kleiner Reibungspunkt. Dokumentation, Oberfläche und auch viele Bezeichnungen innerhalb der API sind spanisch. Natürlich lässt sich heute fast alles schnell übersetzen, aber gerade während der Recherche ist jeder zusätzliche Übersetzungsschritt eine kleine Unterbrechung im Flow. Wenn man sich gleichzeitig durch Endpunkte, Parameter und Rückgabefelder arbeitet, fällt das stärker auf, als man zunächst denkt.

Trotzdem ist das Jammern auf hohem Niveau. Ich bin AEMET dankbar, dass die Wetterstations- und Klimadaten überhaupt so strukturiert offen bereitgestellt werden. Registrierung, API-Key, zweistufige Antworten und kleine Zeitfenster machen den Weg etwas umständlicher, aber die Dokumentation war für meine Zwecke brauchbar und der Zugang ließ sich vergleichsweise schnell herstellen.

Mein Downloader und der Mapper, gewissermaßen die beiden Motoren hinter der Klimachronik, waren innerhalb weniger Stunden "spanisch" 🇪🇸 ¡Olé! :D

Quellen und Ressourcen

AEMET OpenData und technische Unterlagen

Stand:18.08.2026