Please also see the API FAQ for answers to general API questions.
Remember to truncate the results to max 4 decimals to facilitate caching.
A. This is used to adjust temperature according to elevation (and nothing else). While we have a built-in topographical model in locationforecast this is rather coarse, so to get the most precise answer you should add the surface altitude (meters above sea level) of the location for the forecast.
This is meant to indicate the ground height above sea level only. You can not use this parameter to ask for e.g. wind speeds at > 10 m above ground (e.g. for wind turbines, hanggliding and so on).
A. The forecast is now updated at different times depending on location. You should instead use the common caching headers in the HTTP response and use an
If-Modified-Since header in your request. For more information, see the Locationforecast HowTo Guide.
A. The JSON (and XML) contains two different types of data, most data are valid for a exact time and place. Temperature, cloudiness, pressure, wind are all examples of this kind of data, and are listed in JSON under
instance (in XML, the from and to attributes are equal).
Precipitation and weather symbols are computed for a period of time. It doesn’t make sense to talk about how much it rains at 12:00, but how much it will be raining between 12:00 and 13:00. In JSON this is indicated typically as
next_6_hours. Precipitation is given for set intervals (one, six or twelve hours), if you need precipitation for other periods, you must compute it by yourselves.
Weather symbols are just calculated using the other parameters (cloud, temperature and precipitation) and is mainly a way of showing many parameters in one symbol. These must be computed for the interval the symbol is going to represent, you can’t just add them. This is the reason why you find some periods with only symbols and no precipitation.
A. We have tried earlier to calculate local time from geo coordinates, but this is exceedingly difficult and created a huge amount of problems. To sum up, the following steps are necessary to get the correct result:
Find the correct country from the coordinates by using detailed polygons for borders, including territorial waters (local time at sea is even more complicated).
Find the relevant timezone inside the country, which often change due to politics (e.g. Russia and Venezuela in recent times).
Figure out if daylight savings time is in effect (in USA this can vary from county to county).
Compute local time from UTC + timezone + DST.
While the localtime libraries in the OS can help with 2 and 4, it is much easier to use a place name database which usually contains all the necessary information (this is what we do at Yr.no with GeoNames).
A. The Beaufort scale data has been removed to make the output language independent. It’s trivial to translate from windspeed to Beaufort in your own language by using the standard table, e.g. from Wikipedia:
A. The “feels like” temperature on Yr is based on the heat index and wind chill factor, both of which can be calculated from the existing data in locationforecast:
- Heat index is only used when the temperature is > 26°C and humidity > 40 %, otherwise the real temperature is used.
- Wind chill factor is only used when the temperature is < 10°C and the wind speed is > 1.33 m/s, otherwise the real temperature is used.
Note however that there is no standard formula for apparent temperature, but varies from website to website. Ideally, solar radiation should be part of the calculation, however this is not usually included in meteorological observations and will have to be obtained elsewhere. The formula used on Yr can be found on their help pages (text in Norwegian).
A. See the Weathericons repo on GitHub for a list of meanings in various languages, plus a set of icon files you can download and use in your applications.
A. This is mentioned in the WeatherIcon docs:
You can potentially try to reconstruct the weather icons in the API from the locationforecast data. A description of the symbolalgorithms is too long to document and support officially, but you can have a look at the source code if you are interested.
Q. Is there a known mapping from the fog value predictions given by the MET public API to visibility in meters?
A. The only information on visibility from the fog value is to use the definition of fog (visibility less than 1 km)
A: The source for the global weather forecasts is the HRES model from ECMWF:
The only adjustment is interpolation from model grid points to the specific location and an adiabatic height adjustment of air temperature. We use local observations and do extensive post-prosessing of the forecast for the Nordic countries and in the Arctic region. But being a service funded by the Norwegian government we do not have the resources to do this for Australia.
The data used in locationforecast at api.met.no is available from thredds only for the Nordic countries and the Arctic. We are not allowed to distribute freely the global gridded files from ECMWF.
Source for the Nordic countries:
Temperature forecasts :