Weather data

In this section, we explain the basic concept of weather data integration.

Meteorological conditions

This list provides the meteorological conditions which can be integrated by default:

​Meteorological condition


Unit /

Value set


Apparent ("feels like") temperature



Human felt temperature, determined by air temperature, wind speed, and humidity.

Cloud coverage ratio


[0, 1]

Ratio of sky occluded by clouds.

Dew point



Ambient steam saturation temperature.

Relative humidity


[0, 1]

Ambient ratio of steam saturation.

Quantity of ozone



Quantity of ozone substance over an area unit in Dobson Unit.

Precipitation intensity



Amount of precipitation per time unit.

Precipitation probability


[0, 1]

Precipitation probability based on historical meteorological conditions.

Sea level air pressure



Air pressure, measured at the height of the weather station, reduced to sea level.




Ambient air temperature.

UV index



Defined by WMO, WTO, and ICNIRP commision.

Average visibility



Measurement of the transparency of ambient air.

Wind direction


° [0,360]

Direction from which the wind is coming. 0° at true north, clockwise. Not defined for wind speed = 0.

Wind gust speed



Maximum gust speed.

Wind speed



Horizontal wind speed.

We store every meteorological condition as a separate datapoint on the platform to historicize its state. More on this in the subchapter Datapoint and observation convention.

Prediction horizons

Besides the current state of a meteorological condition some use-cases require prediction data. We offer hourly predictions up to 168 hours (7 days) in the future and update them every hour. On ordering you can flexibly choose which horizons you need. The predicted states are aligned to the top of the prediction’s timestamp.

We combine every prediction horizon with the meteorological state monitored to create unique datapoints. You can use the unique datapoints to address the historicized meteorological conditions and their predications on the platform. More on this in the subchapter Datapoint and observation convention.

Datapoint and observation convention

Like any other datapoint on the platform the weather datapoints are identifiable by an alphanumeric identifier which is unique for each project. The timeseries data for particular weather datapoints is stored as observations with a tuple of value and timestamp.

The naming convention for weather datapoints is:

aedifion_weather-<name of meteorological condition>_<preiction horizon>

How we handle predictions: Every predication exists of a predicted value and the timestamp in the future the predication is made for. This timestamp is equal to the prediction horizon. We hold on to this prediction value and prediction horizon combination to make predictions accessible on It’s easier to explain in an example:

Imagine the following setup:

  • The project aedifion office wants to use temperature and dewpoint conditions.

  • This data is needed for a prediction horizon of 1h and 3h in the future.

  • The current date time is 2020-02-20 22:00:00.

Now, how would the datapoint string-id for temperature with 1h prediction be, and which timestamps will be used for the most recent predictions of the dewpoint datapoints at the current date time?

  • The datapoint string-id for temperature with 1h prediction horizon will be aedifion_weather-temperature_1h .

  • For datapoint aedifion_weather- dewpoint _1h: 2020-02-20 23:00:00

  • For datapoint aedifion_weather- dewpoint _3h: 2020-02-21 01:00:00

Your use-case is not covered by the weather data services provided? Do not hesitate to contact us.