API Concepts

Frost is a RESTful API that provides access to MET Norway's archive of historical weather and climate data. This page contains useful reference documentation related to usage of the API. Contact us if you have more detailed questions.

  1. Getting started.
  2. API version
  3. Authentication
  4. Authorization
  5. Weather and climate element identifiers
  6. Calculation method
  7. Available timeseries
  8. Time specification
  9. Relationship between referenceTime, timeOffset, and timeResolution
  10. Geometry specification
  11. Search filter
  12. JSON filter
  13. Resources, schema, parameters, verbs
  14. Hypermedia
  15. CORS
  16. Localization
  17. Mailing list



Getting started

The Frost API is primarily for developers who need to develop scripts or applications that access MET Norway's archive of historical weather and climate data. The API is easy to use; all you need is an e-mail address.

To get started using the Frost API:

  1. Request your client ID and client secret on this page and store them in a safe place. (Side note: While analogous to user name and password, the client ID / client secret is really a different concept. For starters, user name and password are typically defined by the user rather than being auto-generated by the API). Note that the client secret is only required in certain cases to get access to restricted data. Many users will only need the client ID.
  2. Play with and learn more about the resources available in API Reference. The client ID must be copied into a special field near the top of the page before issuing requests.
  3. Begin developing your application. All calls must be authenticated with your client ID. To authorize access to restricted data, you require an access token acquired through the OAuth2 client credentials grant (as well as permission to access those resources). Note that the vast majority of data on this service is open, so the authorization flow is only rarely required.

The client ID is used to identify your application. There are currently no hard data retrieval limits on use of the API (these may come later). A client ID that places undue strain on the server infrastructure during this period may be deleted without prior warning.




API version

The Frost API is currently in version v0 and will remain so until a proper procedure for handling version updates is in place. Please refer to the NEWS section on the toplevel page for the current status.




Authentication

Requests for data (typically everything else than static HTML-pages) must be authenticated with a client ID, either by using Basic authentication without a password, or by using OAuth2 in combination with a client secret and an access token. Note: OAuth2 must be used for authorizing access to confidential data, while both Basic authentication and OAuth2 may be used to access freely available data.

Basic authentication

Example using curl:

      curl --user <client ID>: "https://frost.met.no/observations/availableTimeSeries/v0.jsonld?sources=SN18700&elements=wind_speed"
      

Note: The colon after the client ID indicates an empty password field.

Note: In the API Reference, you can paste the client ID into a special field near the top of the page in order to authenticate calls. Alternatively, if you try to access a resource call without authenticating, the browser will usually pop up a credentials dialog where you can paste the the client ID into the username field (leaving the password field empty).


OAuth2 authentication

Using OAuth2 is a two-step process: First generate an access token by passing the client ID and client secret to the auth/accessToken endpoint. Then use the access token to get data. The access token typically expires after 24 hours, after which a new one must be generated.


Examples using curl:


STEP 1, generate access token:

      curl -d 'client_id=<client ID>&client_secret=<client secret>&grant_type=client_credentials' 'https://frost.met.no/auth/accessToken'
      
STEP 2, use access token to get data:

      curl -H 'Authorization: Bearer <access token>' 'https://frost.met.no/observations/v0.jsonld?sources=...&elements=...&referencetime=...'
      
This example shows how the OAuth2 protocol can be used to access Frost from a Python script.


Authorization

Some data available through Frost are confidential and require authorized access using OAuth2 (see above). Note: Accessing such data must be done using a special client ID and client secret provided by MET Norway, i.e. credentials generated with the self-service solution will not work.




Weather and climate element identifiers

See an overview of the available element identifiers (IDs) in the Table of Weather and Climate Elements (experimental!). 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




Time specification

The Frost time specification is based on UTC time and ISO-8601, extended with repeating intervals which do not exist in the ISO standard.

NOTE: Intervals follow standard inclusive/exclusive semantics; i.e., [0,1) representing a value that is equal to or greater than 0, and less than 1.

As per the ISO standard, repeating time intervals are repeated immediately after each other. So, for example:

R4/2005-07-01T00:00/2005-07-01T06:00

Represents the four consecutive time intervals:

2005-07-01T00:00/2005-07-01T06:00

2005-07-01T06:00/2005-07-01T12:00

2005-07-01T12:00/2005-07-01T18:00

2005-07-01T18:00/2005-07-02T00:00

For repeating time points, we use the interval of only a time point, and add a duration:

R4/2005-07-01T06:00/2005-07-01T06:00/P1D

Represents the repeating four time points 06:00 UTC, separated by a duration of 1 day, i.e. once a day:

2005-07-01T06:00/2005-07-01T06:00

2005-07-02T06:00/2005-07-02T06:00

2005-07-03T06:00/2005-07-03T06:00

2005-07-04T06:00/2005-07-04T06:00

For repeating intervals, we add a duration that represents the time between the start points of the interval. So for example:

R4/2005-07-01T00:00/2005-07-01T06:00/P1D

Represents the four time intervals (separated by a duration of 1 day):

2005-07-01T00:00/2005-07-01T06:00

2005-07-02T00:00/2005-07-02T06:00

2005-07-03T00:00/2005-07-03T06:00

2005-07-04T00:00/2005-07-04T06:00

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




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. P1D means once a day.

TimeOffset is observation time relative to midnight.

Case 1: Observations with timeResolution < 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

Instantaneous observation values with timeResolution ≥ 1 day are also stored as observations with date and time in the data storage. The referenceTime is equal to the observation time, and timeOffset should not be added to referenceTime.

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

Case 2.1: Diurnal 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.2: 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.3: 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.4: Annual data

Annual data cover the calendar year. In this case, referenceTime and timeOffset 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'.




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.


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



Hypermedia

The API currently supports Hypermedia through swagger, via the reference endpoint.

https://frost.met.no/reference


CORS (Cross Origin Resource Sharing)

Currently not enabled.




Localization

Currently not enabled.




Mailing list

The following mailing list can be used for posting questions about usage of the API and for receiving important announcements:

http://lists.met.no/mailman/listinfo/datametno-users