Comment by meteo-jeff | Hacker News Reader

Comment by meteo-jeff | Hacker News Reader

Parent Full thread

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

Hi Geoff,

I currently build ensemble based modelling solutions for bushfire/wildfire. Weather is a significant component in how fire behaves and is forecast. Whilst I have access commercially to several models and meteorologists through work I'd be keen on chatting with you a little further about the possibility of including fire weather metrics in your forecasts, or at least using the data in bulk if possible to include in my own public facing project.

Sure, what kind of fire weather metrics could be added? Can they be derived from soil moisture, temperature, wind, humidity? Or are you referring to gridded fire indices from a different source?

For now I would refrain to include data that is non-date or has restrictive licences.

You can find my email on the open-meteo site and drop me some information

Just to give you a quick reply here, because its late here:

Yes, the basic fire weather metrics are derived from the factors you mentioned. Different places globally have some different measures, but I can speak to Australia, Greece, Portugal, California style setups. Northern US and Canadian pine forests are a little more outside my area of knowledge, but could locate more info easily enough.

I wouldn't wish to pursue a project using commercial IP or introduce additional costs where none should exist.

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 ;)

    < 0z run >
      < 3z run>
        < 6z run>
          < 9z run>

Data is constantly merged into a time-series. The API then selects the appropriate start time, which is set to 0:00 UTC (or if a timezone is set, local-time at 0:00, which could be 4:00 UTC depending on the utc offset).

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.

I wrote my top-level comment about missing ensemble forecasts[1] before I saw this answer of yours. Is the German weather service offering the public access to ensemble forecasts?

And, more critically, since I like your API: will you offer public access to ensemble forecasts? That would make my life better.

[1]: https://news.ycombinator.com/item?id=28520616

German weather service does offer ensemble weather forecast. You can find it here - https://opendata.dwd.de/weather/nwp/icon-eps/grib/. DWD also has excellent documentation.

Thank you for that. I run a home dashboard for my family that includes weather forecast from openweathermap.

This morning I decided to change the provider because the forecast is really unstable.

I will be glad to try yours and give feedback if you are interested. I am near Paris.

Reply on news.ycombinator.com