Show HN: Weather API for non-commercial use
open-meteo.com
Show HN: Weather API for non-commercial use
1–10 of 154 posts
Re: Show HN: Weather API for non-commercial use
#2Creator from Open-Meteo here, I build a small, but very fast and precise weather forecast API for non-commercial use. I am a private individual working on it in my spare time.
Open-Meteo started as an exercise to process weather model data from the German weather service with up to 2 km resolution. Their forecasts are great, but hard to use for non-data-scientists who regularly work with NetCDF and GRIB-files. Using this data in simple apps, websites, your home-automation software, or robot lawn mower is complex.
The Open-Meteo API makes using this data easier. APIs accept standard WGS84 coordinates and return a weather forecast for 7 days in hourly resolution.
The forecast quality is surprisingly good. Open-Meteo includes global and regional weather models. Global models use 11 km resolution with up to 180 hours of forecast. Local models vary between 2 and 7 km resolution and 48 to 72 hours. Updates every 3 hours. The best model is automatically selected and combined to produce a single 7-day hourly forecast. Currently the best forecast model coverage is in Europe. Models for North America will be integrated next.
Under the hood, all data is stored in binary files using Float16 and updated in-place after a new weather model arrives. The API is very efficient. Returning weather forecasts takes usually less than 5 milliseconds. Internet latency is usually much higher.
All data is offered for non-commercial use. With speedy APIs, all data can be served by just a couple of virtual machines for less than a coffee a day.
What’s next? Some important features are still missing like daily aggregations, additional weather models, ocean, and air quality forecasts. Additionally, I would like to deploy some servers in North America and Asia to improve latency.
The project went live 2 weeks ago and is slowly being used. I would be grateful for feedback, suggestions, ideas, and questions.
All documentation can be found at https://open-meteo.com/en/docs
Re: Show HN: Weather API for non-commercial use
#3I've investigated and tried several (free) weather API's for my web app: https://uw.leftium.com.
Open-Meteo looks pretty good! The only thing that seems to be missing for me is precipitation probability. The weathercode is sort of a proxy for this... I'm also interested in sunrise/sunset times; direct_radiation is kind of a proxy for this.
Kudos for providing optional historical data with the same API call for the forecast. Many weather API's don't provide historical data, and even if they do, it requires extra calls. My weather app charts the previous two days of weather with the forecast for comparison. I feel this gives a more intuitive sense of the weather vs. raw numbers because weather is very relative. ("Warm" vs "cool" depends on your location and season.)
In addition, I am in the process of adding AQI forecasts, which requires even more network calls. It seems like this is on the roadmap for open-meteo. I was surprised to find there are so many different standards for AQI. Curious to know which one you plan to use.
One possible suggestion for optimizing the output format: sending seconds since the Unix epoch would save a few bytes per timestamp. I'm not sure if this would make any noticeable difference with gzip compression. The current datetime format is much more human-readable and may save a conversion before displaying.
These were the best (free) weather API's I could find. It's interesting how the three different weather forecasts can disagree so much:
- https://openweathermap.org/api
- https://www.visualcrossing.com/weather-api
- https://darksky.net/dev (deprecated)
When I find the time, I will add open-meteo as to my app! I'll probably have more feedback then.
Re: Show HN: Weather API for non-commercial use
#4Very nice! Thank you for posting this.
I run a cronjob which sends me the forecast for the next day based on german weather service MOSMIX forecasts. I am using https://brightsky.dev for this, which makes the clunky xml files of MOSMIX available as a http api.
I’ll definitely check out open-meteo
Re: Show HN: Weather API for non-commercial use
#5I've investigated and tried several (free) weather API's for my web app: https://uw.leftium.com . Open-Meteo looks pretty good! The only thing that seems to be missing for me is precipitation probability. The weathercode is sort of a proxy for this... I'm also interested in sunrise/sunset times; direct_radiation is kind of a proxy for this. Kudos for providing optional historical data with the same API call for the f…
Thanks for your suggestions!
I will add precipitation probability as soon as I include 14-day ensemble weather models. Deterministic whether models usually do not offer this directly.
I also really like the 2 days historical access :) At some point I would like to add more, but the storage requirements skyrocket quickly. Not only in space, but also disk IO to perform in-place updates.
For air quality data I want to add first all variables individually. AQI can be calculated afterwards on-the-fly. Some AQI indices require data from the previous hours, but it should work well with 2 days past data. For sure I will directly integrate the European and US AQI.
I considered unix-timestamp instead of ISO9601 string timestamps. Working with unix-timestamps is a bit trickier if you also want to use timezones. For the start, i settled with ISO8601 timestamps. I might consider adding unix timestamps as an `&timeformat=unix` parameter to the API. Regarding saving bytes in the output: I would like to implement protobuf as a format and also use it to build some SDKs. Especially with large floating point arrays, this saves a lot of parsing time and preserves precision.
All your suggestions are now kept in the Open-Meteo backlog https://github.com/open-meteo/open-meteo/issues
Re: Show HN: Weather API for non-commercial use
#6I've investigated and tried several (free) weather API's for my web app: https://uw.leftium.com . Open-Meteo looks pretty good! The only thing that seems to be missing for me is precipitation probability. The weathercode is sort of a proxy for this... I'm also interested in sunrise/sunset times; direct_radiation is kind of a proxy for this. Kudos for providing optional historical data with the same API call for the f…
Thanks for your suggestions! I will add precipitation probability as soon as I include 14-day ensemble weather models. Deterministic whether models usually do not offer this directly. I also really like the 2 days historical access :) At some point I would like to add more, but the storage requirements skyrocket quickly. Not only in space, but also disk IO to perform in-place updates. For air quality data I want to a…
Cool! I think unix timestamps should always be in UTC (no timezone). But the timezone may affect the exact time range of the results.
What does "starts at 0:00 today" mean? Ideally, it is 0:00 of the local timezone. (Some other weather API's mess this up!)
Re: Show HN: Weather API for non-commercial use
#7Earlier quoted context omitted.
Thanks for your suggestions! I will add precipitation probability as soon as I include 14-day ensemble weather models. Deterministic whether models usually do not offer this directly. I also really like the 2 days historical access :) At some point I would like to add more, but the storage requirements skyrocket quickly. Not only in space, but also disk IO to perform in-place updates. For air quality data I want to a…
Cool! I think unix timestamps should always be in UTC (no timezone). But the timezone may affect the exact time range of the results. What does "starts at 0:00 today" mean? Ideally, it is 0:00 of the local timezone. (Some other weather API's mess this up!)
At whatever time of day you call the API, data always starts at 0:00. Either UTC or the time zone you selected.
Many weather APIs follow weather model runs. Therefore in the evening, data suddenly starts at 12:00 UTC regardless of the timezone. It is quite a pain, if you want to build an app displaying todays data, but in the evening you do not get data from the morning anymore.
With Open-Meteo multiple weather model runs are merged together and partly overwritten. At around 4:00 UTC, the first weather model with data starting at 0:00 UTC arrived (usually called 0z run). 3 hours later, the 3z run arrives with data starting at 3:00 UTC. After a couple or model runs arrive, it is quite a mix out of different weather model runs. If done right, you notice nothing of this behaviour ;)
Yes, unix-timestamps must be in UTC+0. If a timezone is set, data still starts at "2021-09-13T00:00", but this is now local-time. With a 4 hour UTC offset, I would have to set the unix-timestamp to "2021-09-12T20:00" and the developer has to correctly reapply the UTC offset again to get local time. This can be done, but is prone to errors.
Re: Show HN: Weather API for non-commercial use
#8Very nice! Thank you for posting this. I run a cronjob which sends me the forecast for the next day based on german weather service MOSMIX forecasts. I am using https://brightsky.dev for this, which makes the clunky xml files of MOSMIX available as a http api. I’ll definitely check out open-meteo
I also tried brightsky.dev, but it is limited to weather stations in the MOSMIX system. IRRC only Germany. In terms of forecast quality, MOSMIX should be great!
One goal of mine, would be to provide historical data of the past months to enable users to run their own statistical forecasts combined with weather models. It is actually quite easy to use measurement data and correct forecasts using simple machine learning models like random forrest. If you compare wind speed measures and forecasts, there usually is a simple statistical error that can be reduced easily. Maybe in the next month I will to some tests and example code
Re: Show HN: Weather API for non-commercial use
#9> All data is offered for non-commercial use. With speedy APIs, all data can be served by just a couple of virtual machines for less than a coffee a day.
Very impressive! What does your backend stack look like? Are you using any caching or does every API call hit the binary file?
> The project went live 2 weeks ago and is slowly being used.
What kind of traffic are you getting?
Looking forward to future updates!
Re: Show HN: Weather API for non-commercial use
#10> All data is offered for non-commercial use. With speedy APIs, all data can be served by just a couple of virtual machines for less than a coffee a day. Very impressive! What does your backend stack look like? Are you using any caching or does every API call hit the binary file? > The project went live 2 weeks ago and is slowly being used. What kind of traffic are you getting? Looking forward to future updates!
The API backend is written in Swift with some code in C (conversion Float16, interpolations, some solar radiation libraries). Data are read directly via mmap from local NVMe SSD disks. To scale, I can add new VMs and copy my binary files.
There is no frontend cache and I want to keep it this way. Next steps include point-of-presence API virtual machines in different counties. Via GeoDNS this is even faster than a CDN.
Peak API usage was around 50.000 API calls per hour, but on average it is quite low.