Examples Authentication API concepts Browse weather elements Data clarifications

API Concepts

Below you will find explanations of concepts that will help you to extract data using Frost.

  1. Weather and climate element identifiers
  2. Calculation method
  3. Available timeseries
  4. Time specifications
  5. Relationship between referenceTime, timeOffset, and timeResolution
  6. Geometry specification
  7. Search filter
  8. JSON filter
  9. Default level and timeoffset
  10. Resources
  11. HTTP verbs

Weather and climate element identifiers

See an overview of the available element identifiers (IDs) in the Table of Weather and Climate Elements. The IDs are defined for use in Frost API and are, as far as possible, based on CF standard names and structured as a calculation method.

Calculation method

A calculation method defines in detail how a particular element is derived, typically by combining statistical functions in different ways.

The following combinations are currently available:

CombinationExample
<base name>air_temperature
<method>(<base name>)accumulated(precipitation_amount)
<method>(<base name> <period>) best_estimate_sum(precipitation_amount P1M)
<method>(<base name> <period> <addition>) mean(air_temperature_anomaly P1M 1961_1990)
<method>(<inner method>(<base name> < inner period>) <period>)mean(max(wind_speed P1D) P1M)
<method>(<inner method>(<base name> < inner period>) <period> <addition>) integral_of_deficit(mean(air_temperature P1D) P1M 17.0)

Where the components are defined as follows:

ComponentDescription
base nameThe primary quantity. Normally this is a basic physical quantity. It is normally in accordance with the CF standard name table or CF guidelines for construction of standard names.
methodThe main method (function), applied either directly to the primary quantity or indirectly via an inner method.
inner methodThe inner method (function), applied directly to the primary quantity and used as argument to the main method.
periodThe period over which the main method is applied. This is an ISO 8601 duration such as P1D (one day) or P1M (one month).
inner periodThe period over which the inner method is applied. Also an ISO 8601 duration.
additionEn extra, context-dependent quantity applicable to the main method. It could be a numerical threshold (like 17.0) or a reference period (like a normal period of the form <from-year>_<to-year>, e.g. 1961_1990).

A more detailed description of the various calculation methods is available directly from the elements endpoint.

Methods and time periods correspond to cell methods and time bounds in the CF convention.

Available timeseries

Each data value from the endpoint availableTimeSeries has parameters as shown in the following example:

         ...
        "sourceId" : "SN10380:0",
        "level" : {
          "levelType" : "height_above_ground",
          "unit" : "m",
          "value" : 2
        },
        "validFrom" : "2005-01-04T00:00:00.000Z",
        "timeOffset" : "PT0H",
        "timeResolution" : "PT1H",
        "timeSeriesId" : 0,
        "elementId" : "air_temperature",
        ...
        "sourceId" : "SN10380:1",
        "level" : {
          "levelType" : "height_above_ground",
          "unit" : "m",
          "value" : 2
        },
        "validFrom" : "2005-01-04T00:00:00.000Z",
        "validTo" : "2006-01-31T00:00:00.000Z",
        "timeOffset" : "PT0H",
        "timeResolution" : "PT6H",
        "timeSeriesId" : 1,
        "elementId" : "air_temperature",
        ...

sourceId: SN<station identity number>:<parallel sensor number>. The recommended official sensor has by default parallel sensor number 0, unless the user specifically requests a parallel sensor. Periods with parallel sensors are typically used in the process of replacing an old sensor with a new. SN<station number> is by default alias for SN<station number>:0

level: Used for weather parameters which are measured at different heights or depths.

validFrom: Start of (this part of) the time series.

validTo: End of (this part of) the time series. Note that even though a time series may be split into several parts by the end point availableTimeSeries, the entire time series with SN<sensor number>:0 and timeSeriesId:0 can independently be retrieved by the end point observations as one long time series.

timeOffset: Observation time relative to midnight.

timeResolution: Period between each data value, i.e. data output frequency. P1D means once a day. PT6H means data values every 6th hour. If the timeResolution differ between night and day, the shortest timeResolution is given.

timeSeriesId: :0 or :1 where timeSerieId:<parallel time series number>. The recommended official time series has by default "timeSeriesId":0, and is provided unless the user specifically requests "timeSeriesId":1.

elementId: Weather element identity. List of available elements can be found here.

Time specification

The Frost time specification is based on UTC time and ISO-8601. In addition, when using repeating intervals, Frost allows the distance between the starting points of consecutive intervals to be specified explicitly (this is not part of ISO-8601). By default, this distance is the length of the interval, i.e. a zero gap between consecutive intervals.

NOTE: Intervals in Frost are open-ended: [t0,t1>, i.e. representing times later than or equal to t0 and earlier than t1. The only exception to this rule is when the two times are identical, in which case the interval is considered a single time point.


The basic forms available for expressing time in Frost are as follows:
  • date: YYYY-MM-DD
  • time: hh:mm:ss
  • datetime: <date>T<time>
  • interval (from, to): <datetime>/<datetime>

So you can define a simple time range by writing: 2017-01-01/2017-02-01. The time will default to T0, so this example will get you all of January (from midnight on 01 January until midnight 01 February).

NOTE: As a convenience, the time specification may in certain contexts consist of the word 'latest' to request the most recent data.


For further (more complicated) specification of time intervals the concepts below can be used:
  • Period: P #
    • Y (year), M (month), W (week), D (day), T (time), H (hour), M (minute), S (second)
  • repetions of the interval: Rn/<datetime>/<datetime>
    • for example: R4/2017-01-01/2017-01-02 this gives you data for 1 day, repeated over 4 days. However this is really no different than defining the full time range 2017-01-01/2017-01-05
  • repeating intervals with explicit starting point distance: Rn/<datetime>/<datetime>/<period>
    • for example: R2/2017-01-01/2017-02-01/P1Y (see drawing below)
  • repeating time points: Same as repeating intervals with explicit starting point distance, but with the added restriction that the two times of the interval are identical.
    • for example: R4/2017-01-01T12/2017-01-01T12/P1D (see drawing below)

Below is a visual representation of this time expression:

Where Fi = F + i * period


When using repetitions, express a gap between intervals by adding a period at the end. For example:


represents the two time intervals:

2017-01-01/2017-02-01

2018-01-01/2018-02-01


To repeat a single time point, specify an interval with two identical time points and make sure to add an explicit starting point distance:

represents the four time points:

2017-01-01T12

2017-01-02T12

2017-01-03T12

2017-01-04T12

Relationship between referenceTime, timeOffset, and timeResolution

Each observation value has a referenceTime, timeOffset, and timeResolution as shown in the following example:

          ...
          {
          "sourceId": "SN18700:0",
          "referenceTime": "2017-01-01T00:00:00.000Z",
          "observations": [
          {
            "elementId": "sum(precipitation_amount P1D)",
            "value": 0.1,
            "unit": "mm",
            "timeOffset": "PT6H",
            "timeResolution": "P1D",
            ...

TimeResolution is the period between each data value, i.e. data output frequency. "timeResolution": "P1D" means one data value once a day.

TimeOffset is observation time relative to midnight. "timeOffset": "PT6H" means that the daily data value has observation time 06:00 UTC. If “timeResolution”: “PT12H”, “timeOffset”: “PT6H”, it means that the first data value has observation time 06:00 UTC and the second at 18:00 UTC.

Case 1: Observations with timeResolution shorter than 1 day

Observations with shorter timeResolution than 1 day, are generally stored with date and time in the data storage. The referenceTime is then equal to the observation time, and no timeOffset should be added to referenceTime to get the original observation time.

Case 2: Observations with timeResolution 1 day or longer

Observations with daily or longer time resolution can be stored without a time in the data storage. If a time is found in the data storage, then frost will use this time, if not it will use the first midnight on the given date.

NOTE: If referenceTime is different from midnight, referenceTime is equal to observation time and timeOffset should not be added.

Case 2.1: Instantaneous observations
An instantaneous observation represents a time point, not a period. E.g. an instantaneous temperature observation vs. an average temperature over a longer period of time. Instantaneous observations with timeResolution ≥ 1 day are stored with date and time in the data storage, unlike other observations with timeResolution ≥ 1 day. The referenceTime is equal to the observation time, and timeOffset should not be added to referenceTime.

Case 2.2: Diurnal (daily) data

Diurnal data represent a 24 hour period on a specific date. They are stored with date only in the data storage with a referenceTime of the form <year>-<month>-<day>T00:00.

If timeOffset = PT0H, the observation value represents the period from midnight to midnight on the calendar date, i.e. from <date>T00:00 to <date>T23:59.

If timeOffset != PT0H, the observation represents the last 24 hr, at the time after midnight equal to timeOffset. E.g. elementId = sum(precipitation_amount P1D) has timeOffset PT6H. This means that the observation period lasts continuously from the previous date at 06 UTC to current date 06 UTC. ReferenceTime <date>T00:00 is just the specific date for the diurnal value. The end of the observation period, is referenceTime + timeOffset.

Case 2.3: Monthly data

Monthly data are aggregated data. They are stored with observation time as <month> and <year> in the data storage. Day 1 is added to the referenceTime: referenceTime = <year>-<month>-01T00.00, i.e. the date of the first day in the observation period.

If timeOffset = 0, the monthly value represents the calendar month, midnight to midnight. The referenceTime is of the form <year><month>-01T00:00, i.e. the start of the observation period.

If timeOffset != 0, the monthly value represents the period from p1 to p2 where p1 and p2 are midnight + timeOffset on the last day of the previous and current month respectively.

As an example, element ID sum(precipitation_amount P1M) has timeOffset PT6H. This means that the observation period lasts from <year>-<previous month>-<last day of previous month>T06:00 to <year>-<current month>-<last day of current month>T06:00. I.e. the value of February 2018 has referenceTime = 2018-02-01T00:00 and is based on the period from 2018-01-31T06:00 to 2018-02-28T06:00.

Exception: Old monthly minimum air temperature, min(air_temperature P1M)em> from 1894-1937 were calculated using the average minimum temperature of 2 days, and is hence based on the period from <year>-<previous month><last day of previous month> to <year>-<month next month><first day of next month>

Case 2.4: Seasonal data

Seasonal data represent the periods of spring (1 March - 31 May), summer (1 June - 31 Aug.), autumn (1 Sep. - 20 Nov.), winter (1 Dec. - 28/29 Feb.), winter half year (1 Oct. - 31 March), and summer half year (1 April - 30 Sep.).

In this case, referenceTime is set to the start date of the seasonal period, e.g. for spring:
referenceTime = <year>-03-01T00.00

TimeOffset follows the same rules as for monthly data.

Case 2.5: Annual data

Annual data cover the calendar year. ReferenceTime and timeOffset for annual data follow the same conventions as for seasonal and monthly data.

Geometry specification

Geographic location in Frost is expressed in terms of either a single point or a polygon area. Coordinates are expressed as longitude and latitude based on WGS 84.

Geometry objects in the JSON output follow the GeoJson format, as specified in IETF RFC 7946.

When querying, geometry is expressed using a syntax based on Well-known text:

Syntax Description
POINT(10 59) Refer to the exact point given by the geometry object with longitude 10 and latitude 59 in WGS84 projection.
nearest(POINT(10 59)) Refer to the item closest to longitude 10 and latitude 59.
POLYGON((10 59, 10 60, 11 60, 11 59, 10 59)) Refer to the items inside the polygon starting with longitude 10 and latitude 59 etc. Note: polygons with holes are not supported by the Frost API.

Search filter

The standard search filter is case-insensitive and supports asterisks ('*') to represent zero or more characters.

For example, 'f*n*d' matches 'Finland', 'Fagerstrand' and 'FV395 Ålesund'.

JSON filter

A JSON filter is a special type of JSON object that consists of zero or more key-value pairs: "<key1>": "<value1>", "<key2>": "<value2>", ... The braces around the object may be omitted, like in this case. Each value is a comma-separated list of search filters.

For example, the request:
https://frost.met.no/elements/v0.jsonld?sensorLevels="values":"2","levelTypes":"height_above_ground"
matches elements with sensor level type height_above_ground and sensor level value 2.

Default level and timeoffset

Data is sometimes returned in multiple timeseries, with different level heights or time offsets. This is because several sensors are installed, and several aggregation periods may be in use. To help reduce this to a single timeseries per element, these parameters can be specified as levels=default and timeoffsets=default.

For levels, this will exlude any data which is not measured at a standard level for each element. If both level and timeoffsets are filtered in this way, then levels will also be filtered first.

For timeoffsets, you will be given the best time offset option available. When offset values matching the standard value is available, that will be returned. If not, but if a time offset of PT0H is available, this will be returned as a second best. If this is not available either, then the first or only timeseries will be chosen.

Note: timeoffsets=default will only compare timeseries that have identical parameters other than time offset. It will not reduce the number of timeseries that differ in time resolution, level, sensor number or timeseries id. To ensure a single timeseries per station and element, timeresolutions should be set, and both levels and timeoffsets should be set to default or to a specific value. (If no specific sensor or timeseries id is specified, these will always default to their standard values.)
Also note that measurement time is not considered, so if the time offset of a timeseries changed over time, only the data measured with the most preferred time offset will be returned. These cases are very few, but it does occur.

Resources

The Frost API provides a RESTful API centered around resources. These resources can be acted upon using the standard HTTP verbs. Descriptions of the available resources can be found in the API Reference.

HTTP verbs

The Frost API attempts to use appropriate HTTP verbs to perform actions on resources.

Verb Description
GET use to retrieve data
POST use to load data to the API (requires Authorization)
PUT use to update data in the API (requires Authorization)
DELETE not permitted at this time