The starting impulse of Climate Chronicle

Austria was my first country. At the beginning I did not fetch the data via the API, but directly through GeoSphere's graphical interface: Station data klima-v2-1m.

That is also how I downloaded the entire historical holdings. For the first prototype, to be honest, I did not yet want to deal with the API and open a second construction site. Through the graphical interface I got to the data relatively quickly, even though I kept hitting limits. Especially with Austria and its very long historical series, this manual path eventually became quite tedious.

Still, exactly this quickly available data was enormously important for the project. I do not know whether I would have continued building Climate Chronicle at all if I had first had to spend a long time on data access, APIs and different formats. At the beginning I mainly wanted to see whether my idea could work at all; above all I was somewhat unsure whether I could display thousands of stations dynamically at the same time.
The data simply had to be there so that the dashboard, mapper and later the whole processing chain could emerge. That Austria could deliver a large volume of historical measurement data simply and without barriers was decisive for the start.

In the middle of the country flow, in August 2026, it was time to integrate Austria properly. The GeoSphere API is clearly structured: host, version, type, mode and resource ID follow a fixed schema. The documentation is understandable, and after a whole series of foreign-language docs, working in my native language is much more pleasant. That saves time!

The metadata endpoint delivers the station list, parameters and the dataset period directly. The series starts in 1768. For the station IDs already integrated, I only had to remove the AT_ prefix and the rest matched the API directly.

Historical and current data run through the same endpoint klima-v2-1m. The only difference is the time range. Columns such as time, station, tl_mittel, tlmax, rr and the remaining metrics are recognized directly by a dedicated AT import profile. As soon as CSV arrives, mapping and further processing kick in without detours.

The official limits are: 5 requests per second, 240 per hour and a maximum of 1,000,000 values per request. With blocks of about 100 stations and 30 years plus the currently active 11 measurements and 11 quality flags, you stay under one million. For the historical first import, roughly 108 requests are enough. The response header datapoint-count also shows the actually calculated request size.

That makes the download extremely fast.
A rough comparison: the AT package of historical data takes about 2 minutes to download and is about 200 MB in size. The Norway package with a similar architecture, by contrast, took about 100 minutes and was about 4 GB - much slower and much larger - even though I only downloaded the needed metrics across all years. Okay, Norway has 3x more stations; Austria has much longer series instead, and even if you scale by a factor of 3, you can clearly see that AT has built this very efficiently.

Requests still have to be sliced carefully. Station or time blocks that are too large exceed the value limit. Keep the blocks clean and you stay in the safe zone.

The graphical interface is enough for first access, but not for a regular, reproducible production download. With a little over 1,000 stations and about 260 years of history, you keep hitting limits there. That is why the early GUI path was project-saving, but not a lasting solution.

The old host dataset.api.hub.zamg.ac.at must no longer be used, by the way. Redirects were ended at the beginning of 2026. Anyone still using old links or scripts will hit a dead end.

Austria was the starting impulse of Climate Chronicle: quickly available, strong on substance, and reachable via the interface at first. The API itself is very well made and, compared with other countries, pleasantly clear and very transparent. There is even an API changelog (I love that 😁) where improvements and new features are communicated on an ongoing basis.

One thing stood out to me there: in the move from klima-v1 to klima-v2, parameter names were changed among other things. For me that was not an issue now, because I started directly with v2. For a future v3, though, it would be nicer to keep the old names running as aliases - otherwise you would still have to adapt quite a bit.