What changed from Frost v0 to Frost v1?

Important only if you have been using frost.met.no v0 (the previous version of Frost) up to now and want to start using v1

Frost v1 is backwards compatible

You can still use your old v0 queries for the observations endpoint with a change of DNS name (examples to come).
However, we cannot guarantee that this will work indefinitely!

Filter or Kafka? New API endpoints

There are now two endpoints from which you can get observations: filter and kvkafka. Most people should use
filter, because it will return only the recommended timeseries. However, some internal MET users may want to use kvakfa in order to chose very specific timeseries.

Changes to the way you do the searching

In Frost v0, you had to do the searches in several steps. Often you would start by searching for the meteorological stations situated in your area of interest, then their available timeseries and elements. You would use the results of these searches to construct a final search for the observation data.

In v1 this process has been simplified so that you can search directly for the data without knowing about the stations or timeseries.
Use one of our location or geospatial search parameters to define the area of your search and look up the elements if you want to do a direct search for data.

You can of course still do separate searches for metadata if you want (set the new parameter incobs to False), but the syntax has changed. The best way of testing this would be to use the API interactive documentation to explore the new options.

Note the default settings!

The API offers many request parameters (e.g. qualitycodes, stationnames etc) and you can choose to use them or not. In Frost v0 the standard behaviour was for the API to always return every available value if a request parameter was not set by the user. In Frost v1, there are two types of behaviours when a request parameter is not set:

• The API will return ALL available values (most parameters)
• The API will apply a default setting for the parameter and return only values that match this default setting; you will find these default values in the list of request parameters

Note: keyword "all". If you want all available values for a parameter with a default setting, you can usually use the keyword "all". Check the list of request parameters to check when you can use this keyword.

Changes in the names

Some request parameters have new names, and there have also been some changes to what search terms you should use. The list below contains the most common parameters that have changed:

• referencetime changed to time
• sources changed to stationids (and the station id number should no longer start with "SN"!)
• elements changed name to elementids
• qualities changed name to qualitycodes