New version of MetAlerts coming 2024-04-02

We have been working on a new version 2.0 of MetAlerts, which is expected to replace the current version 1.1 in May. A short summary of the most important changes:

• New endpoints with a more logical organization
• A new CAP profile with more data parameters
• Improved and fully supported location search
• Improved GeoJSON output with more data

In the new version we have the following endpoints:

/current - only currently valid alerts
/all     - every alert for the last 4 weeks (same as "show=all" in 1.1)
/test    - "fake" alerts for test purposes
/archive - previously issued alerts since 2019

All endpoints support output in RSS, GeoJSON and CAP (XML) formats. Positional search (lat=...&lon=...) works for all endpoints, but is much faster (except for /archive). Some features are still marked as experimental, but will become stable in May on the official launch.

New parameters have been added, including:

• riskMatrixColor - shows the alert level (yellow/orange/red)
• incidentName - name of extreme weather for red level alerts (e.g. "Hans")
• altitude/ceiling - vertical extent of the alert

Also, the documentation has been vastly improved. Lists of parameters with explanations are now available for both CAP profiles (v1 and v2), and the GeoJSON format now has a proper spec, and is not expected to change until the next version.

We hope users will take a look at the new version and update their systems before version 1.1 is terminated, probably after the summer. More information will be given on the mailing list when the new version is out of beta.

Intermittent disruptions of service 2023-12-07

On Monday afternoon (Dec 4th) we had a severe outbreak of planned maintenance, which resulted in disruption of most MET services between 15:00 and 18:00 UTC. To cut a long story short, someone tried to turn off some old DNS servers which were thought not to be in use, which resulted in DHCP overload and most VMs becoming unresponsive. From what we can see, api.met.no was unavailable for about 1 hour and 39 minutes, although delivery varied from product to product.

The admins have identified the problem, and made some adjustments so that similar incidents should not happen again. Next week they will restart all services in order, after which they will make another attempt to turn off the old DNS servers. We don't expect any downtimes on api.met.no, but if you should experience problems during the following time periods, no action is needed:

• Tuesday, Dec 12th 2023 between 08:00 and 10:30 UTC
• Wednesday, Dec 13th 2023 between 08:30-10:30 UTC

In addition they are also changing some network components which are likely to cause some short disruptions in our services. We had about 3 mins downtime on Tuesday (Dec 5th) around 09:30 UTC, although it is difficult to see if it affected the whole API or just our monitoring systems. More maintenance was planned for today, but postponed due to critical weather conditions. The current plan is to upgrade the remaining components on Monday (11th) at 09:00 UTC, when there might be some short interruptions of service. We're sorry for the inconvenience, but hopefully things will be stable during the xmas period.

As for the rest of the API, there have only been a few minor changes the last six months:

• A new product IsobaricGRIB is in beta, delivering gridded aviation weather data for parts of Norway (with more to follow)
• We're also working on Subseasonal, a new product currently very much in beta delivering 21-day forecasts for the Nordic region
• Maritime Gribfiles have been updated with a new model, where wave directions have been swapped so that map plotters should show them correctly
• The weather icons have been moved to GitHub, and the WeatherIcon API service has been terminated

Plans for next year include migrating to new servers during February, hopefully with better performance. We are also busy implementing the OGC API EDR standard, which is likely to be the predominant search interface for all MET services in the future and something you might like to read up on.

New versions of Sunrise, Turbulence and more 2023-05-31

While it's almost been six months since the last update, we have been quite busy and have several important announcements to make before the summer break.

Sunrise 3.0

The venerable Sunrise version 2.0, which is our second most popular product, is being retired. Consisting of 100K lines of Fortran code, it has become impossible to maintain after the main developer left us, and is being replaced with a much smaller Python library which uses GeoJSON as its standard output format instead of XML. You can find the source code on Github:

https://github.com/metno/celestial

The full astro application has a whole host of features which was never used by the API, including a GUI planetarium where you can see planetary orbits in real time. If you are interested in astronomy we urge you to check out this project, wishing it will have a long life outside of MET:

https://github.com/FrankThomasTveter/astro-api

Version 3.0, which has been in beta for many months is expected to be officially launched on 15 June, at which time version 2.0 will be deprecated. We plan to support the old version until 31 August, so you should have plenty of time to port your client application to the new JSON format. (Note also that the new version is much stricter with regards to identification in the User-Agent header.)

https://api.met.no/weatherapi/sunrise/3.0/documentation

New aviation products

On 8 June we will be launching a new version of the Turbulence map product, using Machine Learning and a much higher update rate (every 3 hours for 18 hours ahead, instead of only every 12 hours). The current version (1.1) will be terminated on 10 July 2023.

https://api.met.no/weatherapi/turbulence/2.0/documentation

At the same time we will also be launching a new product for offshore helicopter flight maps. This was previously available under the Routemaps product, but now has several more areas and a higher update frequency:

https://api.met.no/weatherapi/offshoremaps/1.0/documentation

Changes to marine products

Due to popular demand, we will soon be deploying a new marine simulation model (WaveWatch) in Gribfiles which follows the meteorological convention of the values indicating where the waves are coming from (instead of going to as in the current version). This means you finally will be able to input the GRIB files into your marine chart plotter and see the waves going the right way! There is no change in the API interface so file downloads will work as before, but check the Changelog to see when the new files are being deployed.

https://api.met.no/weatherapi/gribfiles/1.1/changelog

We have also recently added three new harbours to the Tidalwater product:

• Bruravik (BRJ)
• Leirvik (LEH)
• Sirevåg (SIE)

Removal of the WeatherIcon service

Whereas in older versions we had a functional API, the current version of WeatherIcon is only indended as a one-time download of an archive of icon files. Still, many users are hotlinking the icons and downloading the static file "legend" for every request, causing a lot of unnecessary traffic. As a consequence we will be removing the weather icons from the API, moving it instead to the documentation and only allowing the icons to be downloaded offline. This is planned to terminate on 31 August.

Odds and ends

We are rolling out a new field updated in the Available JSON feed. By comparing this timestamp with your previous downloads you can easily check if there's any new files to be downloaded without having to make separate requests for each. This feature is gradually being ported to each API product separately.

We are also working on adding solar influx to the global Locationforecast "complete" JSON output. This has been a much requested feature and is of special importance to the solar industry. Delivery has been delayed but expect to see it late this year. You can already find it in the Nordic model NetCDF files as integral_of_surface_downwelling_shortwave_flux_in_air_wrt_time:

https://thredds.met.no/thredds/dodsC/metpplatest/met_forecast_1_0km_nordic_latest.nc.html

Finally, as some of you may have noticed we have redesigned both the API and documentation web pages, with a responsive design that finally works on mobile devices and is WCAG compliant. Please let us know if you have any comments or suggestions as we are always trying to improve the usability of the API.

Have a great summer (or winter, if you're in that part of the globe)!

Changes to MetAlerts 2022-12-14

MetAlerts

You might notice some changes in the CAP XML format for the warnings. Up to now, all the CAP files have contained only one area per info block, and only one polygon per area element. We have now done some changes in how we produce the CAP files, and some warnings may contain several polygons per area element.

This has always been allowed according to the CAP standard. Since it has not been used in the CAP warnings from MET Norway up to now, we suggest you check that your systems can handle this.

Note that in case of overlapping polygons, the are covered is the total of all the polygons, with no holes. According to the CAP standard:

if multiple <polygon>, <circle> or <geocode> elements are included, the area described by this <area> block is represented by the union of all the included elements.

Textforecast 3.0 beta

We have also been busy making a new version of the Textforecast product, this time in GeoJSON format which many of you have asked for. This means that the coordinates are now included in the JSON file, instead of having to be looked up separately. You can test it here:

https://api.met.no/weatherapi/textforecast/3.0/documentation

Currently only the land and coast forecasts are included in the beta, sea forecasts may follow at a later date.

Other products

A new version of the Turbulence charts are expected to be released in beta on Feb 1 2023. We are also working on a new version of Sunrise, this time in native JSON which many of you have asked for. Stay tuned for more updates.

New version of Routeforecast 2022-06-30

Routeforecast

Due to changed requirements the horizontal maps will be discontinued on Sept 1st. The only product still available after that date will be the vertical cross sections (vcross).

Since this is a breaking change and lots of stuff in the interface and documentation suddenly becoming redundant, we have decided to make a new version 2.0 with only the vcross images as can be found here:

https://api.met.no/weatherapi/routeforecast/2.0/documentation

Version 1.0 is now deprecated, and will be removed on 2022-09-01.

From our logs there were hardly anyone using the horizontal maps, but users of the vcross images must now update their URLs to the new format:

https://api.met.no/weatherapi/routeforecast/2.0/?route=....

(Also note that the new version is stricter about identification than before, so if you haven't already set a User-Agent header with contact information this is a good time to do so.)

Changes to MetAlerts and NLAroutes 2022-05-22

MetAlerts

From 1 June 2022 there will be some changes in the CAP warnings in MetAlerts:

https://api.met.no/weatherapi/metalerts/1.1/

Some of the area polygons will now be drawn freehand by the meteorologists, and will be in better agreement with the actual weather situation. We will still use geocode "county" and "municipalityId" for the affected administrative areas, but geocodes NUTS3 and iso will no longer be included in the CAP file.

We suggest that users of CAP warnings make some extra checks after 1 June to ensure their systems are running as intended. If you should find any discrepancies, please contact us.

NLAroutes

Next week, the number of available routes will increase from 27 to 86. Also, the time period covered will decrease from 66 hours to 22. This should result in a reduction in the number of files in available from 50 to 7-9 per route. Also, the number of timegraph locations will increase from 55 to 75.

To assist in sorting and filtering images, we will also be adding a new "region" parameter to the available list, e.g.:

https://api.met.no/weatherapi/nlaroutes/1.0/available.json?region=middle

The following regions will be available for both routes and locations:

north, middle, southeast, southwest, coast, old

After a short grace period to enable you to change your systems, the routes and locations in the "old" region will be removed. This is planned to be implemented on 1. July, and will affect the following routes and locations:

Total of 16 routes: AAL-ENRT, ENAN-ENAT, ENAT-ENSS, ENBO-ENVR, ENLX-ENBG, ENLX-ENFL, ENLX-ENKH, ENLX-ENRT, ENLX-ENSX, ENLX-ENTS, ENLX-XZFR, ENMS-ENRA, ENRA-ENBO, ENTC-ENMH, ENTS-ENRT, ENZZ-ENKB

Total of 13 locations: ALVDAL, AURLAND, BLAKSTAD, BYKLE, DALSBYGDA, ELVERUM, GULSVIK, NORDREISA, NOTODDEN, SPYDEBERG, TANA, ULLENSVANG, VEGGLI

Server park upgrade, changes to aviation products and more 2021-11-08

New API servers

On Wednesday 10 Nov we will start moving the API traffic to a new server cluster which promises much better performance, due to faster processors and extensive use of SSD disks. Hopefully this will result in shorter response times and a higher turnaround. We'll start propagating the changes via DNS around 10:00 CET. We have done extensive testing of the new servers, but since the file distribution chain is a separate system it could possibly happen that some data have been forgotten by the backend producers. If there are something you feel is missing, please let us know ASAP at weatherapi-adm@met.no.

The change will at first only affect traffic going to https://api.met.no/. Those with special arrangements (other domains) will be notified later when it's time to move their traffic.

Aviation product changes

We will shortly be adding 22 new routes (vertical cross sections) to Routeforecast. At the same time we will be reducing the number of time steps from the current 84 to 22 (as stated in the documentation). This should result in better performance in generating the available lists.

There will also soon be a similar increase in the number of routes for NLAroutes, as well as a similar reduction in time steps.

The new sigcharts version 2.0 with Nordic maps is expected to go out of beta on 1 December, at which time we will deprecate the current version (don't worry, you will have time to migrate after the New Year).

We will also soon be launching a new option in Tafmetar, giving additional information such as AMD and COR (for TAFs), as well as COR, SPECI and AUTO (for METARs). These will prefix the existing messages, and can be enabled by using the parameter extended=true. More information on this later.

Finally, the IGA warnings will be removed from Aviationforecast in December.

EOL for the old Yr API

As previously mentioned, the "free weather data" API on yr.no is going away, and will be turned off completely on 1 February 2022. This will affect both the XML data (varsel.xml and forecast.xml) and the HTML widgets currently used on many websites. Until then the services will suffer planned outages of increasing length, informing developers of the need to change to newer services.

For more information, see the Yr Developer docs or contact NRK at support@yr.no.

https://developer.yr.no/doc/guides/deprecating-old-widgets/

New version of available?

Finally, we are planning to replace our existing, home-grown "available" method with something a bit more effective, preferably using existing standards. It has been more or less unchanged since the launch of the API in 2007, and since then the amount of available files has grown enormously (we currently deliver over 5000 files for some products). This means the complete list can take several seconds to generate, which is a problem for the total API performance.

We are looking at some of the new OGC standards, which fully support OpenAPI and should in time hopefully be supported by standard libraries for the most used programming languages. If you are interested you can find some documentation here:

https://ogcapi.ogc.org/edr/overview.html

If you have some specific requests for new features in the "available2" functionality we would very much like to hear from you.

New beta version of sigcharts 2021-07-14

A short update, mainly of interest to Nordic users:

Sigcharts 2.0 beta

We have a new version of Sigcharts which, in addition to the previous Arctic/Norway also covers the Nordic/Baltic regian (minus Iceland). Also, the search interface has been made consistent with the rest of the API:

https://api.met.no/weatherapi/sigcharts/2.0/documentation

While currently in beta we suggest you start using this after the summer is over. We're not sure how long the current version 1.0 will live, this depends on how soon our regular users will take to implement the new version.

Forestfire index

As mentioned some weeks ago, the Forestfireindex product has been terminated and replaced with a new, map-based service:

https://skogbrannfare.met.no/

For those wishing to download the raw data used for the maps, these can now be found on our THREDDS server:

https://thredds.met.no/thredds/projects/fwi.html

TOS addition

With the ongoing migration of users from the Yr API to api.met.no, we've had to update our Terms of Service with a notice on trademark restrictions:

You are not allowed to make services/sites that appear to be made by Yr, NRK or The Norwegian Meteorological Institute. In other words, you may not use the word "yr" as a part of your service name, or attach the yr logo to your service.

https://api.met.no/doc/TermsOfService

This was previously only stated on the conditions of use on yr.no, but as the old Yr site (retro.yr.no) is closing down soon we've had to transfer the clause to the api.met.no TOS (incredibly, some users are still referring to this as the "Yr API", even though they were two different APIs and Yr is a completely different site run by the Norwegian Broadcasting Corporation).

Forestfireindex EOL July 1st 2021-06-01

Some product changes, mainly of interest to Norwegian users:

Forestfireindex

This product will be terminated on July 1st, as it has been replaced by MetAlerts on the new Yr website. We are working on a new map-based service, which is currently in beta and available on skogbrannfare.met.no.

The old retro.yr.no site will link to this after July 1st. We are also working on making the raw data files avaiable on thredds.met.no as NetCDF files, more info on this later.

Sigcharts

On June 1st we will start using a new tool for making SIG-WX charts. The images will look somewhat different and have other dimensions, but will be available on the same URL as before. We are planning to add a Nordic map later, in which case we might be bumping the version number. More info on this later.

Lightning warnings

On June 15th, we will add a "lightning" type to MetAlerts. This will only be of yellow severity, and signify events with a large amount of lightning strikes.

Routeforecast

On June 1st, the route Korpfjell-ENKR will be removed, and the Stangnestind-ENKR route added.

Probabilityforecast and old Oceanforecast EOL July 1st 2021-05-10

As mentioned earlier, Oceanforecast 2.0 is now in production and version 0.9 has been deprecated, to be removed on 2021-07-01. Despite what we said earlier there will be no change in the XML format for 0.9, as we have extended the EOL of the backend model to the same date. (The experimental XML version in 2.0 is also going away, although later in the summer).

The Probabilityforecast product has also been deprecated and will be removed on 2021-07-01. As a replacement we have added the following new variables to complete.json in Locationforecast/2.0:

air_temperature_percentile_10
air_temperature_percentile_90
wind_speed_percentile_10
wind_speed_percentile_90

We have also improved the handling of requests outside coverage for Nowcast and Oceanforecast (2.0). Any requests outside the model area (as defined by the shapefile which can be downloaded from the /coverage endpoint) will get a 422 error response. Any requests within the model area but which we have no data for (either due to lack of radar range or ocean forecasts for dry land) will get a GeoJSON response with an appropriate error or warning message.

Note that we have implemented a "snap" functionality in Oceanforecast so land points near the coast will return the nearest point at sea (this means the coordinates in the URL and JSON may be different). The new model areas can be seen on the maps here:

• https://docs.api.met.no/doc/oceanforecast/datamodel
• https://docs.api.met.no/doc/nowcast/datamodel

Finally, as you may know we have not supported unencrypted HTTP for several years, and all requests to port 80 have been redirected to the corresponding HTTPS URL. Yet, after several years we still get a lot of traffic from old systems which has not been updated to use HTTPS, which in some cases could be considered a privacy liability. As a consequence we have decided to drop this feature; now all requests to po 80 will be redirected to the front page of the API.

New version of Oceanforecast, and more 2021-03-26

Questions to the administrators

We're always getting a steady stream of questions from API users, and after terminating Locationforecast/1.9 this has peaked significantly. Unfortunately, almost all of the questions are variations of two themes:

1. Why am I being blocked with a 403 response?
2. What kind of other data do you have except for the API?

While the first one is easy to answer (read the documentation), it's also the hardest to solve (people don't read documentation). So again, if you have problems and must contact us, please make sure you a) have set an identifying User-Agent header and b) give us you IP address so we can check our logs for problems.

The other one is more complicated. While we have many products on api.met.no and several other APIs as well (e.g. Frost), most of the data we produce are really only meaningful for scientists, and quite complicated to process for people with only general programming experience. The data are stored as NetCDF files in our THREDDS archive, which is administered by another team. Us API guys don't really know much about the data residing there and how to use them, so we can only forward such questions to the scientists or the thredds admins.

To direct your attention in the right direction, we have made a thredds landing page which contains a useful starting point in where you can find scientific data and documentation how to use them. This is now linked in the product list on api.met.no:

https://api.met.no/product/THREDDS

If you have questions regarding those data, please don't use the weatherapi-adm address as this goes directly to the API admins. Instead send an email to thredds@met.no to ensure your questions go to the relevant personnel.

Oceanforecast 2.0

Some of you have already noticed this, but we have quietly launched a new beta version of Oceanforecast which now uses the same FORTI backend and JSON format as the latest Locationforecast and Nowcast. Unlike the others the new version will only offer JSON output, as the MOX XML format is excessively complicated and we can no longer find the spec(!).

Also note that the wave direction has been changed from oceanographic convention ("going to", similar to currents) to the more common meteorological convention ("coming from", similar to wind), as shown here:

0.9 XML:
<mox:mean\TotalWaveDirection uom="deg">89.7</mox:mean\TotalWaveDirection>

2.0 JSON:
"sea_surface_wave_from_direction": 269.7

Please take a look at the beta and start porting your existing applications shortly.

We'll be polishing up error messages and verifying the data in the 2.0 beta until May 1st, when version 0.9 will be deprecated. At the same time we will switch so that both versions use FORTI as backend since the old Nordic-4km model is going away. This might mean some trivial differences in formatting and some values might be different due to more detailed simulations. You can get a preview of the MOX output coming to 0.9 here; note though that this link will be removed after May 1st:

https://api.met.no/weatherapi/oceanforecast/2.0/mox?lat=60.10&lon=5

Changes to the API

We've made some extensions to the available listings, which can be summarized as follows:

• added labels to JSON (previously only in XML format)
• added endpoints to JSON and XML where applicable

This means the available lists can now support links with endpoints, like we've been using with /complete.json and /classic.xml in Locationforecast. Also we have added extra validation of legal parameter values for all products.

Yr API translation table

As promised for some time, NRK has made a dump of their placenames database so that users of the old Yr API (varsel.xml and forecast.xml) can now easily change from the old Yr API URL to both api.met.no and the correspond pages on the new Yr site. Note that the api.met.no string can be used with both locationforecast, nowcast and other products inside the coverage area.

The links are available for all countries in the world, in both English and Norwegian (bokmål and nynorsk). You can download them as zip archives of CSV files from here:

https://developer.yr.no/doc/guides/getting-started-from-forecast-xml/

MetAlerts archive

By popular requests, we have made available archives of historical alerts going back to January 2019. This means that developers can now easily simulate different alert types in their apps even when no warnings have been issued simply by turning back the clock. To use the archive, just specify the desired year and month with the "period" query parameter. See here for examples:

https://api.met.no/weatherapi/metalerts/1.1/documentation

Also, we have removed the link to the RSS alert feed from the available list, so it now only lists the CAP files which makes more sense as both basically do the same thing.

Probabilityforecast nearing EOL

This is the final product which has not yet been ported to FORTI. Due to changed requirements for the new Yr.no site we have decided to terminate this as a separate product, and instead add some more probabilty data to complete.json in Locationforecast. This is already in testing in-house, and will be launched publicly after Easter, at which point Probabilityforecast will be deprecated. Final EOL date is not yet determined, but sometime this summer is our best guess.

Termination of various products 2021-02-04

All good things must come to an end, hopefully to be replaced by something better. Here is an update of forthcoming changes to the weather APIs.

Locationforecast and Nowcast

As mentioned previously, the old versions of Locationforecast (1.9), Nowcast (0.9) and Weathericon (1.1) will terminate on March 1st, 2021. Incredibly, almost 70 % of the current API traffic is still using version 1.9, This means a lot of sites and apps will stop working shortly. We recommend everyone not yet upgraded to start working on this ASAP. Please see our docs for more information:

https://docs.api.met.no/doc/

Yr APIs

The Yr API (forecast,xml and varsel.xml), developed by the Norwegian Broadcasting Corporation NRK is also set to expire this summer, along with the old Yr site (retro.yr.no). All Yr API users should port their applications to use Locationforecast/2.0, noting the following differences:

• Yr API uses XML, we recommend JSON for Locationforecast
• Yr API uses placenames, for Locationforecast you must use lat/lon/altitude
• Locationforecast requires identification in the User-Agent header

For more information on porting from Yr, see the developer site:

https://developer.yr.no/

Also, NRK is working on a one-time dump of their location database, which will give you the correct coordinates and altitude to use with Locationforecast and Nowcast, as well as the URL to the forecast on the new Yr site. This is expected to be ready in a few days. Please follow the mailing list or one of the sites above to get information on where to download it.

ExtremesWWC

As indicated, this product has long been deprecated, pending new functionality on Frost for the same purpose. Unfortunately this has not yet materialized, and now the production chain for ExtremesWWC is no longer supported. As a consequence we will turn it off tomorrow, February 5th 2021. Since this product only covers Norway and has only a handful of users, we hope you will forgive us the short notice.

Important changes to locationforecast and nowcast 2020-12-15

After several months in beta, Nowcast 2.0 is finally officially launched. Both this and Locationforecast have now got a definite date for termination of the old versions.

Continuation of XML format

Based on popular feedback we have decided to continue the XML format for Locationforecast and Nowcast into the foreseeable future. For this purpose we have added a /classic XML variant to Nowcast, which is basically identical to the version 0.9 format. This means porting from the old version should be much faster than rewriting to use JSON.

To support the XML format in the future, we will extend it to include the new symbol codes as introduced in Weathericon 2.0. Please use this instead of the numerical codes which are now deprecated. Starting today the symbol elements will look like this:

<symbol id="PartlyCloud" number="3" code="partlycloudy_day"/>

You can then link this to the partlycloudy_day.png icon which can be downloaded in Weathericon 2.0.

Some future additional changes to the XML format are to be expected. Some time within the next six months we will remove the following elements from the XML format; please don't use them in your clients:

<temperatureProbability unit="probabilitycode" value="0"/>
<windProbability unit="probabilitycode" value="0"/>
<symbolProbability unit="probabilitycode" value="1"/>

Termination of old versions

Now that both products have been finalized, we have decided it is time to say goodbye to the old versions, hailing from 2014 and 2016 respectively. On March 1st, 2021 the following products will no longer be available:

• Locationforecast 1.9
• Nowcast 0.9
• Weathericon 1.1

Please update your systems to use the new version if you haven't already. If you keep running into 403 Forbidden errors, remember that according to the Terms of Service you must identify yourself with a unique User-Agent HTTP request header with contact information.

New version of Yr.no

As some of you may have noticed, yr.no now points to the new version (formerly the mobile site) and the old layout has been moved to retro.yr.no. The latter site is expected to be turned off in the summer of 2021; at the same time the old Yr API (varsel.xml/forecast.xml) will disappear. By this time users must have converted to use Locationforecast/2.0 for continued service.

The Yr developers at NRK are working on making a downloadable dump of the existings locations database, mapping place names to lat/lon coordinates. We'll be back with more information on this once we have something to report.

Minor changes to other products

Sigcharts has gotten a new parameter validdate which makes it possible to see which day a plot is valid for. This is now included in the available list.

Turbulence has had some airports removed and Vigra airport added. We have also enabled search by ICAO code instead of location name; this will become the default search method in the future (which means the links in available will use icao instead of location parameters). We recommend updating your clients to use this at your earliest convenience.

New Nowcast and return of Geosatellite 2020-10-02

Nowcast 2.0 beta

After the very successfull update to our Locationforecast service, we have now upgraded Nowcast to a similar modern spec. New features include:

• a new JSON format, very similar to Locationforecast
• radar precipitation coverage extended from only Norway to include Sweden, Finland and Denmark (currently only northeastern parts)
• real-time corrected temperature forecasts for the whole MEPS area, see the data model documentation

While some parts are still missing (documentation, JSON Schema, radar data for the rest of Denmark) it is currently useable enough that you can familiarize yourself with the new data format and start upgrading your clients. Currently we do not have any estimate for how long the current 0.9 version will be supported.

Geosatellite images

After having been unavailable for two years due to licencing issues, we have finally resolved the situation. Unlike previously when only a small subset was available, we are now able to offer you the whole range of EUMETSAT image products under the CC BY 4.0 license.

With over 4000 different images at any one time this also means that the complete available list is very large and may result in timeouts. We therefore urge you to filter this on your specific requirements, e.g. area, type and size.

Future works in progress

We are currently working on updating our Oceanforecast service to the new JSON standard. We have also started on a new project for improving our map services (as seen on Yr.no). During our cooperation with the University of Oslo we have gotten valuable feedback from students regarding map integrations on mobile app development, but we are also very interested to hear from web developers what kind of maps you would like to see and which protocols and formats you would like to see supported.

If you have any feedback, please send us an email at weatherapi-adm@met.no with the subject "Map feature requests". We will later collate this and use for planning new map products which hopefully should be available next year.

Locationforecast 2.0 launch and new Terms of Service 2020-06-12

Locationforecast 2.0

For the last couple of years we have been working on a new forecast backend (FORTI) to replace the decade-old, PostgreSQL-based store (WDB). While Locationforecast/1.9 has been running from FORTI for some months now in "compatibility mode", we have finally finalized the new JSON format which will become standard for all weather forecasts soon.

We are still busy fixing the documentation which is a bit rough in places, but take a look at the JSON format and data model documentation soon.

Version 2.0 comes in three different flavours:

/weatherapi/locationforecast/2.0/complete

This service endpoint will return a response with all available forecast parameters. As we make new forecast parameters available, they will be added to the responses for this service endpoint (we expect to include probability percentile data fairly soon). Also, some geographical areas will have more forecast parameters available than others.

/weatherapi/locationforecast/2.0/compact

This service endpoint will return a response with only a core set of forecast parameters. All forecast parameters in this endpoint will be available for every location. We will add new parameters to this endpoint as well, but much more rarely, and the size will not increase much. If you feel there is some useful parameters missing here, please let us know.

/weatherapi/locationforecast/2.0/classic

This service endpoint exists only for backwards compatibility purposes. The parameters in this endpoint and the XML format provided are identical with /locationforecast/1.9, but with more time intervals. Use this if you have an existing application and want to do minimal work to update it. We don't expect adding any more parameters (XML tags) to this format in the future.

We have also introduced an improved topography for the entire world, which should give more accurate temperature forecasts in some areas. This topography will be used if you do not specify altitude in your request. Note that the improved topography is still relatively coarse. We therefore recommend that you specify your own altitude in the request if you have access to your own topography data.

With great power comes great responsibility. Regardless if you're Voltaire, Churchill or Spider-Man, all users must now adhere to the Terms of Service (more below) more stringently. In particular you must pay more attention to the following rules:

1. You must identify yourself with contact information in the User-Agent request header. Whereas requests without any such header or just a generic string (e.g. "okhttp/3.12.4") until now has been throttled, new products will return a 403 Forbidden instead.

2. Truncate all geographical coordinates to max 4 decimals. There is not point asking for forecasts down to nanometer precision, and makes it impossible to cache data. While we previously have truncated the requests in the cache, this had to be done on a per-product basis. For new products we will instead implement this as a site-wide rule, where requests with 5+ decimals will return a 403 Forbidden.

3. Requests like /weatherapi/locationforecast/2.0/?lat=... have been deprecated. While they will continue working for a limited time, you should always use one of the endpoints above, preferably /compact.

Termination of old products

Locationforecast 2.0 will be officially launched on Wednesday 17 June 2020. At the same time version 1.9 will be deprecated. A final termination date has not been set yet, but we plan on turning it off before xmas.

The already deprecated LocationforecastLTS will terminate on 1 Sept 2020. This gives you almost three months to port your applications to Locationforecast 2.0, if you havent already started.

UVforecast has been deprecated as UV data is now included in Locationforecast 2.0 JSON, and will also be terminated on 17 June.

We also expect to launch a version 2.0 of Nowcast in about a month, using FORTI and the same JSON format as Locationforecast.

Terms of Service

This is mainly a rewrite and clarification of the existing rules. While there is nothing radically new under the sun, the old TOS was confusing and badly organized, so many users missed vital points like User-Agent identification and started asking why they were being throttled. Hopefully this version should be clearer and more detailed.

The new TOS is still in draft state, but if you have any questions please let us know before we finalize it later this month.

Other products

There have been some minor changes to some specialized products:

verticalprofile

The "airquality" profile has been removed

airqualityforecast

New names of counties and municipalities according to the 2020 reform. E.g. "Buskerud/Røyken/Midtbygda/Røyken" has been changed to "Viken/Asker/Midtbygda/Røyken".

All quiet on the Corona front 2020-04-20

Hope you are all doing ok in these difficult times. Here at MET Norway it's business as usual. Most of us are working from home, but since the API team already did this for half the week there's not much difference. Here's a summary of the changes so far this year:

End of Life'd products

The following products have been deprecated and will be removed on 15 May 1 June 17 June 2020:

• UVforecast
• Radar/1.5
• Sigmets/1.0

The following have also been deprecated, probable EOL times as indicated:

• LocationforecastLTS (August 2020)
• Locationforecast/1.9 (January 2021)

New products

Locationforecast 2.0

Version 2.0 is nearing completion, the only major feature missing is documentation. We have decided to split the output into three different endpoints:

• default (new, plain vanilla JSON)
• compact (a lite version of JSON with less bloat)
• classic (good old fashioned XML, to be used responsibly)

Also, the unit for temperature has been changed in JSON from "C" to "celsius" to conform with CF standards.

Weathericon 2.0

We are also happy to launch a new set of corresponding weather icons. Unlike the former numerical codes in 1.9, the 2.0 "symbol_code" variable is based on a mnemonic code and correspond exactly to the icon filename (minus extension). All icons are available in PNG, SVG and PDF formats, and can be downloaded as a gzipped TAR archive:

In addition you can also get a table matching the new and old symbol codes, as well as explanatory texts in English and several variations of Norwegian:

Radar 2.0

Radar have been upgraded to version 2.0, with new parameters, new areas, new sizes and a new projection. GIF animations will still be producted for the time being.

Sigmets 2.0

The new version 2.0 delivers both SIGMETS and AIRMETS, but now also includes wind shear warnings. You can now ask for each type separately, but by default you will get all in the same response. Also the long-standing bug where warnings would be included twice have finally been fixed.

Sigcharts

This was previously part of Upperwindweather, but has now been launched as a separate product.

Other changes

LocationforecastLTS

As mentioned last year we have deprecated the LocationforecastLTS product, which will be retired some time after we have launched the new Locationforecast 2.0. In the mean time, the background model for the Nordic area (MEPS) have been replaced with a new, improved model (CMEPS) which is run every hour.

Unfortunately, some little used parameters are no longer present in the new model, which means that some slight changes have been made to locationforecastlts:

• the parameter areaMaxWindSpeed was removed
• there will no longer be available time intervals backward in time

These changes are only be visible for the Nordic area (Norway, Sweden, Denmark and Finland). The rest of the world (which uses the EC model) remains unchanged.

MetAlerts

Some of you may have noticed that about half of the municipalities in Norway got new codes ("kommunenummer") this year. This was implemented in MetAlerts this March. As you cannot search on municipalites yet (only counties) rhis does not affect the API interface, but if you are extracting kommunenr from the CAP files you should search for both old and new numbers.

New backend

In March we changed the file storage backend for non-dynamic products. This should result in faster response times and greatly reduce the occurence of delivering stale data.

Future plans for 2020

• Icemap/2.0 (possibly with GeoJSON)
• Probabilityforecast/2.0, Nowcast/2.0 and Oceanforecast/2.0 in JSON formats

Ho, ho, ho and some API stocking fillers 2019-12-20

We hope you all have been good developers this year, in which case you can look forward to some new improved products next month (for those who have been bad we will also be taking some away).

Locationforecast

On December 3rd we launched the new backend for locationforecast/1.9. In connection with that some of our users have noted that the topography for Norway is not as accurate as before. This is because we use a terrain model with a slightly coarser resolution. This does not affect the quality of our temperature forecasts. However, due to requests from our users we will soon return to a higher resolution topography for Norway.

Next year we also plan to introduce a higher resolution topography for our global forecasts. This will make the forecast more accurate when not using the recommended "msl" parameter to indicate elevation, which is hard to implement e.g. in mobile apps.

We are also working hard on finalizing the JSON format in 2.0, as well as improving the weathericon symbols so that you won't have to call sunrise to know if to use a night or day version.

Radar animations

Due to popular demand, we have decided to continue GIF animation in radar/2.0 which will launch on Feb 3rd. Everything else will be different though, included sizes (only one), areas (previously called radarsites), types (more options) and formats (all static images are now in PNG).

Radar/1.5 will continue running until May 15th so you have plenty time to update your systems. We still have plans to launch a Javascript animation version, but this is not a high priority.

More changes on Feb 3rd

Next year the sigcharts in upperwindweather will be moved to a new product, possibly with some new charts to follow. The upperwindweather product will then be deprecated, and eventually removed from the public api.

We will also be launching a new version 2.0 of icemap with more and better maps of the Arctic. The old version 1.5 will continue running until March.

We have also decided to retire the little-used lightning product on api.met.no. Since you now can download lightning data more or less in real time from Frost, there is little use for 5 min old data from the API. The data will continue to be delivered in UALF format as before. You can test out the new product here (remember to register for a developer key).

Finally the radar/1.5 and uvforecast products will be end-of-lifed on May 15th, to be replaced by the improved radar/2.0 and locationforecast/2.0 respectively.

Changes to Textforecast and Locationforecast 2019-11-13

We will shortly be making some changes to the existing versions of Textforecast and Locationforecast.

Textforecast

The seahigh and seabank products will be replaced with a new, auto-generated product (named sea) which will be available on December 3rd (possibly earlier). The old forecasts will continue production until February 1st, after which requests will be returned the new sea forecast instead.

Locationforecast

We will shortly be changing the backend for the locationforecast to a new, cloud-based service. For the immediate future there will be very little change for the users except for higher performance. There are some minimal changes to the version 1.9 output, in short:

1. Only 1- and 6-hour forecasts will be supported, the 2- and 3-hour intervals will be removed.

2. We have added precipitation minvalues and maxvalues for the whole forecast for the Nordic and Arctic regions, not just the first two days:

3. The EPS, LOCAL and EC* models in the meta header are no longer relevant. We now how only one model (met_public_forecast), with a single runended and nextrun timestamp.

4. The global forecast (outside the Nordic and Arctic regions) will be shortened by 6 hours. As a compensation it will update every 6 hours, instead of every 12 hours as previously.

If you experience any problems due to these changes, we suggest temporarily switching over to LocationforecastLTS until you can make the necessary changes.

LocationforecastLTS

As Locationforecast and LocationforecastLTS currently runs on the same old backend and is virtually similar, we have decided to end-of-life this product as it is impossible to guarantee the same output on the new backend. This means LocationforecastLTS will be officially deprecated once the new model is in production, but will not be terminated until the end of February 2020 at the earliest (which should be plenty of time to change your implementation). Since the new backend is much faster and has a more correct forecast, we suggest changing over to I as soon as possible.

Plans for next year

Some of the planned changes for the next 6 months include:

Locationforecast

In the long term we will be launching a new 2.0 version, which features:

• a new, proper JSON format (instead of conversion from XML)
• probability values (as in the current probabilityforecast)
• UV index data (replacing the current UVforecast product)
• more understandable weathersymbol codes, hopefully without the need to contact sunrise

At the same time we will be deprecating the Probabilityforecast and UVforecast products since the data will now be available in Locationforecast instead.

Radar and Radarlightning: These will be consolidated into a new version Radar/2.0, with removal of some unused products and replacement of GIF animations with Javascript templates.

UVforecast: These are produced by external parties, and we experienced distribution problems last summer. Since UV data will be available in locationforecast/2.0, the UVforecast product will be terminated after Easter 2020. UV maps should still be available from external distributors.

ExtremesWWC: This product will be replaced by a similar feature on our observations and climate API frost.met.no.

We do not have exact dates for the above changes, but will return with updates once we have more specific information.

I know what your API did last summer 2019-08-21

Making an API is a thankless task. Most users aren't aware they are using it, and you rarely hear from the developers unless something isn't working. While our weather site Yr is hugely popular, our API doesn't get much publicity. So when we finally get some exposure, it's sad to find only negative publicity, and misguided criticism at that. But before addressing the issues, let's watch the presentation (starting about 8:44 into the video).

"...a company called met.no, seems to be a weather type service..."

To start with, met.no isn't a company, it's the Norwegian Meteorological Institute – a state-owned, non-profit government organisation which has as one of its missions to give free (both as in beer and in freedom) weather data to the whole world. So far we've managed to do this without any developer registration or other conditions than nicely asking not to overload our services. As a consequence we have no clue about most of the thousands of apps and sites using our services, and no way of contacting them unless they subscribe to our mailing list or read the API front page.

From the interview one would get the impression we are making apps ourself using unsecure communications. Such is not the case – the only app we have some influence over is the Yr weather app, which doesn't speak with our API at all. So already the (admittedly valid) criticism is targeted at the wrong party.

"... it was making an HTTP request, totally normal"

Disregarding that "it" in this case is an app we have no control over, we have actually supported (and recommended) HTTPS for many years (although in the old API this wasn't default because of compatibility issues). Since the rewrite and launch of WeatherAPI v.3 (which came out in beta in 2016 and was gradually phased in on a per-user basis over the next year) we have only supported HTTPS. All unencrypted HTTP traffic is either being redirected or blocked (more on this later).

To this day we still get complaints about this, e.g. when no longer being able to use Squid as a local caching proxy, or using client libraries which don't support SSL/TLS. Incredible as this may seem in 2019 it is still an issue, and when your application is a watering plant run by a Saia-Burgess PLC controller there is no sofware upgrade path.

About half of the requests to api.met.no are either throttled, blocked or invalid. Of the latter, most are for products which were removed years ago. We're still getting requests for locationforecast/1.8 which was removed in 2014(!). Most developers don't bother checking the response status codes, so lots of sites and apps go on blindingly ignoring 304, 404 and 429 errors for several years. And since many users don't update their mobile apps until they have to, we're getting a lot of legacy traffic, included unencrypted HTTP which we're unable to prevent people from sending us.

As an example, let's look at the HTTP traffic from Android (pre <5.0) apps where the developer haven't read the TOS and uses the default "Dalvik" User-Agent header which amounts to 13% of the total unencrypted HTTP traffic. These are the amount of requests sorted by status code between 12 and 13 today (UTC):

As the table shows, the unencrypted traffic amounts to a whooping 43% of the total identifying only as Android (and an obsolete version at that). How much of this actually handles the redirect is difficult to see as we don't track users, but we find it hard to believe that 76% percent of the HTTPS traffic comes from redirects. This means that a large portion of clients never follow the redirect.

Of those who use HTTPS, an incredible 55% of the HTTPS requests are being throttled for too much traffic or missing identification, while only 43% get a meaningful answer. The remaining requests (apart from a handful of timeouts) are either for products which been discontinued (sunrise/1.1 is still very popular) or they can't manage to construct a valid URL. That's a lot of developers who can't be bothered to RTFM.

"... trying to figure out when the sun goes up"

Now, this is where it gets interesting. Most of the HTTP traffic is actually for locationforecast; sunrise doesn't count for more than about 5%. Of this, 5 out of 6 sunrise requests are actually zombie apps calling version 1.1, which was discountinued in February and returns a 404. (Incredibly we also get some for version 1.0 which was EOL in 2016!)

Still, that leaves about 1% of HTTP traffic for sunrise/2.0, which has never worked with unencrypted HTTP. Every piece of documentation, example code and tests we have published have been using HTTPS, so why are people still using HTTP? These requests are (if identified at all) coming from Android, so either there is something amiss with the Dalvik HTTP client stack, or developers are intentionally breaking security by rewriting our examples from "https:" to "http:". As the saying goes, it's hard to make stuff fool-proff because the fools are so smart.

"Latitude and longitude, that's harmless, right?"

Many of the requests do indeed contain geocoordinates. However, the vast majority of these originate from servers located in data centers totally remote from the geolocation in the request. Even when an app enable location services on your phone, we have no way of knowing if the coordinates are your actual GPS location or if you're just checking the weather for your next trip to Paris. We're still getting ~25,000 different IP addresses from all over the world downloading the weather forecast for a cornfield in Poznan, PL every 5 minutes, amounting to 3.15% of the total api.met.no traffic.

"... but you've got the MAC address [...] and lat/lon"

I confess this claim has us stumped, and after putting our collective heads together we still can't figure out what they're getting at. Sure, the MAC address is an identificator which can be used to link with personal data, but that is never transmitted to us (what the app developers are doing with your personal data you must ask them about).

Now, the only third party getting access to both your MAC address and your unencrypted traffic is either the owner of your Wifi access point/router or your phone operator. Admittedly, both these can be spoofed and your traffic intercepted by evil middlemen. However, in both cases they can already pretty much tell your geolocation even without snooping your data traffic. When a phone is connected to (in this case) a 800mW faked wifi access point and indoors it is pretty much given that the person is within a 50 m radius. In fact this is how shops track customer behaviour, logging how much time each person spends before each isle. Now, having the GPS coordinates in addition would probably give you a better resolution, but then GPS reception isn't great inside buildings anyway.

"So now we can track that person when their phone requests updates"

Actually, no. The API doesn't collect any personal data, except for the ubiquitous access log. We don't even use cookies or Google Analytics, not do we write any mobile apps ourselves. The only potentially identifiable data logged by us are the IP address (which for vast majority is either a website server or a NATed 3G/4G address which changes every time you move into a new cell tower area), the User-Agent string (set by the app) and the URL itself. This log is used for monitoring resources, debugging errors and trying to stem abuse, which is necessary to avoid the tragedy of the commons.

Sure, the app developers can (and probably will) track you, and the same goes for your phone company or free Wifi provider. But that has nothing to do with HTTP encryption, and very little to do with geolocation (which they know already).

HTTP redirects

Now, you might ask why we didn't go directly for HTTPS in the first place. At the time api.met.no was lauched in 2007, this was not usually an option; Facebook didn't offer HTTPS until 2011, and many client libraries did not support it. While this now has changed, our main priority has always been backwards compatibility, something we're proud of having had for 12 years now, even though individual products and versions have come and gone.

As mentioned earlier, all of the unencrypted HTTP traffic is either blocked or redirected, in the latter case to a similar HTTPS URL. Now, since we're mirroring the original URL in the Location response header, it can be argued that we still "support HTTP" since legacy apps can still go on working if they handle the 301 properly. If they instead got a 404, the theory goes, they would see the error in their ways and change their code to use HTTPS instead.

Unfortunately, in practice that is not the case. The sites topping the list of HTTP have all been blocked for abuse and get a 403 Forbidden response. They have been blacklisted for years, but still continue to hammer our servers with 14k req/hour each with no end in sight. For these large websites there is no connection between the IP address and the geolocation received by us, so any "leak of personal data" here would be between the browser and the website if they're not using HTTPS.

If we can conclude that policing obsolete websites is futile, then this goes double for obsolete mobile apps where it doesn't matter what the developer does unless the user updates the app. As can be seen from the previous table, a lot of the traffic isn't only against services which no longer exist, but are also more than two years old and run on obsolete versions of Android. There is not much hope that these apps will be updated any time soon.

Anyway, as a precaution we tried disabling the redirect to HTTPS to see what happened. Not only did we get a lot of support tickets from developers who couldn't figure out what was wrong, it also broke the website. Whereas you previously could type e.g. "api.met.no/apis.json" in the browser location bar and get JSON back, the browser actually defaults to unencrypted HTTP which no longer works. Instead you actually have to type "https://" before the hostname. Can you think of any other sites in 2019 where this is necessary? Me neither.

In fact, all major sites we have tested (e.g. Google, GitHub, Paypal, eBay) redirect HTTP requests to corresponding HTTPS URLs, which is also recommended in all best practice documentation we have found, including the HTTP Strict Transport Security. Here is an example of GitHub doing exactly the same thing:

$ GET -Se http://api.github.com/users/octocat/orgs
GET http://api.github.com/users/octocat/orgs
301 Moved Permanently
Connection: close
Date: Fri, 23 Aug 2019 11:08:56 GMT
Location: https://api.github.com/users/octocat/orgs
Content-Length: 0
Client-Date: Fri, 23 Aug 2019 11:08:57 GMT
Client-Peer: 140.82.118.6:80
Client-Response-Num: 1

GET https://api.github.com/users/octocat/orgs
200 OK

So we've rolled back the change, and until we can find a way to differentiate zombies from actual live humans we're keeping it that way.

The bottom line

So, the next time you hear someone boldly stating that

"APIs leak personal data"

you would be wise to interpret that as

"abandoned zombie apps, written by unknown parties for a defunct API, who send unsolicited, not-very-personal data to non-existent services, can be intercepted by hackers who will learn nothing they don't already know, and there is nothing the API owner can do to prevent it".

Admittedly that won't make any headlines at a security conference. Instead, if there's anything to learn from this, it's that most traffic against APIs is actually noise, which you'll just have to learn to deal with. But admittedly that doesn't make for good soundbites on YouTube.

More changes to Radar and Radarlightning 2019-07-02

Due to increased workload by the new 5 min radar interval, we have had to reduce the number of different images available. In short, generating GIF animations from existing static GIF images continues as before. However, due to the 50% increase in images and 33% shorter production window, generating animations from PNG is no longer possible and has been terminated. We apologize for the lack of advance notice, but we had not foreseen this would be a problem.

Since we know this will cause existing functionality to break, we've come up with a temporary solution where we substitute the missing animations with similar products. In most cases the pixel dimensions will be different, but this can be scaled in the browser. Also note that content=image and content=animation now will return totally different images, so be wary of using size=small for static thumbnails for the animations.

reflectivity_hires and rainrate_with_phase

All animations of type reflectivity_hires and rainrate_with_phase will be substituted with type reflectivity. Where radarsite indicates an area these will be identical, but single radars will be substituted to the closest area as per the following table:

lightning

All requests for lightning animations (including the Radarlightning product) now return the "norway" image. All other animations have been terminated.

We have some images currently used internally which could be substituted for each individual area, but they are currently not available on the API. We will be working on a possible replacement later this summer.

"medium" and "large" size static images

The little used "medium" and "large" sizes have been terminated. All requests for these sizes now return the "normal" image. If you scale this in the browser it should not be noticable to the end users. This does not affect radarlightning which already uses only "normal" size.

Also, the small GIF animations haven't been produced for a long time and will be removed from the API. This means only the following variations will be available in the future:

Again, we're sorry for the inconvenience, but hopefully the faster radar scan rate should compensate for the reduced size options.

Future changes

In closing, we will like to inform you that later this year we'll be releasing a new beta version of the Radar service, with a coherent set of areas and types which should be much more understandable than the current mess. Also, GIF animations will be replaced by Javascript, which should be much more user-friendly as you can then pause or jump forwards and backwards in time to see details.

We strongly suggest you consider dropping GIF animation as soon as possible, since now that most partners are using Javascript or WMS we plan to phase out GIF completely by the end of 2019 sometime during early 2020.

Changes to Radar, Nowcast and other products 2019-06-07

Radar

From Wednesday June 12th, the radar images will be produced every 5 mins.

New features

• new product "aviationforecast", see below
• new beta product "volcanicashforecast"
• sunrise now returns moon position and phase for each day
• routeforecast have several new routes
• upperwindweather now has a status function showing image update and transmission errors (if any)

End-of-life

Spotwind 1.0 has been replaced by 1.1 which delivers data for 24 hours instead of 6. Version 1.0 will expire 2019-09-02.

ExtremesWWC is expected to be removed some time in the near future, to be replaced with a similar feature in our Frost API for observations. We will come back with further news when this is available.

Textforecast 1.6 has been deprecated, and the land and sea forecasts have been re-implemented in 2.0 with a new, cleaner XML format which can now be validated. The aviation forecasts have been moved to a new product "aviationforecast" but remains otherwise unchanged. Since the migration is now complete we will terminate version 1.6 on 2019-09-02.

New API products 2019-03-04

We will shortly launching some new products, mainly of interest for Norwegian users. As described earlier, some obsolete products will also be removed.

textforecast 2.0

We have started the process of cleaning up the old text forecasts, with a new XML format (which can be validated), more consistent data structure and clearly defined areas. All of new forecasts share the same format and schema, including:

• landoverview
• coast_en, coast_no
• seabank_en, seabank_no, seabank_wmo
• seahigh_en, seahigh_no, seahigh_wmo

To aid in transition from textlocation, all areas are now identified with an id, which can be used to look up the corresponding geographical coordinate polygon. These files can be downloaded from the /areas endpoint, but we hope eventually to be able to include them directly in the forecast.

Textforecast 1.6

We have removed the "land" product (use "landoverview in 2.0) as well as "seaoslofjord" (use "coast_no" and "seabank_no" in 2.0).

Airqualityforecast

For some time we have been working on air quality forecasts in cooperation with several other public services. This is expected to go out of beta soon.

Routeforecast 1.0

This is a new image service for aviation, primarily offshore helicopter flights.

Textlocation 1.0

This product will expire March 15th. Please use the "landoverview" product in textforecast along with the area files.

Errornotifications 1.0

This service hasn't delivered any data for months and will expire on March 15th.

ExtremesWWC 1.2

This product will expire on April 1st, when we are turning off the WSklima service (delayed until further notice). There might be a similar service on frost.met.no in the future.

Discontinuation of text forecasts 2018-12-21

As mentioned earlier we are discontinuing some little used products from api.met.no, here is a complete list:

On February 1st we will remove the following products from the textforecast service:

• the route_fbno products (these will still be available for professional users via NAIS which everybody seem to use anyway)

• the landday/long, seabankday1 and metkyst products (which are used to generate more comprehensive forecasts)

• the iga_fbno43, easter and miskred products (which haven't been produced for years)

We have checked the logs and all of these have little or no traffic, so we don't expect them to be missed. This is the full list of discontinued forecasts:

easter, landday0, landday1, landday2, iga_fbno43, landlong, metkyst0, metkyst1, miskred_north, miskred_south, route_fbno69, route_fbno70, route_fbno72, route_fbno74, route_fbno75, route_fbno76, route_fbno77, route_fbno78, route_fbno79, route_fbno80, seabankday1.

Also, on March 1st the textlocation service will be discontinued. We will also remove the "land" product from the textforecast service. There will be another forecast product to replace those two products, details of which are to follow later.

At the same time, the product "seaoslofjord" containing forecasts for Skagerrak and for the Norwegian coast from the Swedish border to Hordaland will be discontinued. Forecasts for Skagerrak can be found in the "seabank" product, while forecasts for the complete Norwegian coastline can be found in the "coast" product.

We will soon also remove the errornotifications service, which is no longer producing any data. This will be replaced by specific status messages for each product.

Changes to GeoSatellite and new privacy policy 2018-06-29

Due to licensing issues, problems with authentication and abuse of the service we have been forced to suspend delivery of non-restricted geosatellite images to the general public. Currently there are only 8 unrestricted pictures from a total of 2162 which we are allowed to distribute freely, but we have seen repeated attempts to download images which are clearly documented as not publicly available. Until further notice the service will only be available for our own sites yr.no and halo.met.no.

Also, as part of the European General Data Protection Regulations, we have updated the privacy policy for all our sites and services. You can find the new text under Privacy Policy Statement for MET Norway.

Planned maintainance and discontinuation of old domains 2018-05-09

On Monday May 14th, 2018 from 07:00 to 13:00 UTC we will be running at 50% capacity due to replacement of the cooling system in one of our data centers. All services are expected to continue running, but latency times and timeout errors may increase due to reduced capacity.

Also, as has been noted earlier, the domains api.yr.no and beta.api.met.no will be turned off on June 11th, 2018. Please switch your systems to use api.met.no instead.

Migration completed 2018-02-26

As most of you probably have noticed, we upgraded api.met.no about A week ago to the new version. After some initial performance problems we managed to tune the caches so it is now handling traffic well.

Some users have reported problems accessing the API, mostly related to not handling HTTPS and/or redirects. If you are getting "Failed to get data from weather api. Reason: end tag name </body> must match start tag name <hr> from line 5" this means you are trying to parse the HTML message as XML instead of following the 301 redirect. We are also working on recommendations for users using HTTPS via local proxies.

In order to ensure stability of our own services, we have also introduced traffic rate limiting (and in some extreme cases, blocking) for some users not abiding by our terms of use. If you are receiving 429 status codes it means you are being throttled, either due to a missing/generic User-Agent header and/or excessive traffic (>20r/s).

Finally, we have noticed there is a lot of production traffic against beta.api.met.no (which was only to be used for testing) as well as api.yr.no (which has been deprecated for years). We would like to inform you that these hostnames will be removed within a few months, so please update your applications accordingly.

Migration of api.met.no 2017-12-12

As previously mentioned on the mailing list, we will shortly be migrating the api.met.no domain to version 3. This has already been done for some users and should be relatively painless, provided you follow the documentation and terms of use. In particular we ask you to notice the following:

• Use HTTPS only! Unencrypted requests are no longer supported
• Honor redirects (301 and 303), which is used e.g. from HTTP to HTTPS
• Semicolon as parameter separator is now deprecated, use ampersand instead
• Make sure you have a unique, identifiable User-Agent string

Otherwise the main difference is a lot of new features and bugs that have been fixed. For more information on the changes to the interface, please see the release notes for version 3.

The migration is scheduled to take place some time during the first half of January 2018.