Weather condition

This is great! I was always wondering how to make DWD data actually usable. It’s a shame they either can’t (weird format) or won’t (legal issues). Although the Warnwetter App seems to have a proper API, so it’s probably the latter.

I’m currently dreaming up a home-assistant integration for brightsky and I’m missing a string describing the weather condition. This is an excerpt from the darksky component:

MAP_CONDITION = {
    "clear-day": "sunny",
    "clear-night": "clear-night",
    "rain": "rainy",
    "snow": "snowy",
    "sleet": "snowy-rainy",
    "wind": "windy",
    "fog": "fog",
    "cloudy": "cloudy",
    "partly-cloudy-day": "partlycloudy",
    "partly-cloudy-night": "partlycloudy",
    "hail": "hail",
    "thunderstorm": "lightning",
    "tornado": None,
}

Is that something that’s available in the data, or is there only numeric data?

[jdemaeyer]

Aalrighty, weather records in the response will now contain an icon field holding one of the following values:

• clear-day
• clear-night
• partly-cloudy-day
• partly-cloudy-night
• cloudy
• fog
• wind
• rain
• sleet
• snow
• hail
• thunderstorm

[jdemaeyer]

Dropping a couple of thoughts into my pensieve after half a day of plowing through raw data and DWD specs:

1. As a first implementation I think we should try to reproduce Dark Sky’s icon field, which can currently take the values snow, sleet, rain, wind, fog, cloudy, partly-cloudy-day, partly-cloudy-night, clear-day and clear-night.
2. Note that this does not include thunderstorm, hail, and tornado, which they mention they might add in the future but never did.
3. For a start I also want to merge clear-day and clear-night into just clear (and likewise for partly-cloudy) to avoid having to deal with sunrise and sunset times.
4. This leaves us with eight possible states (from highest to lowest priority/badness):
   • snow
   • sleet
   • rain
   • wind
   • fog
   • cloudy
   • partly-cloudy
   • clear
5. The icon field should be consistent across all observation types. This rules out directly reading any existing “present weather” field from the raw data, because such fields only exists for current and forecasted weather, but not for historical weather.
6. Using the “Wetterinterpretation” algorithm from above seems very heavy and requires a bunch of meteorological parameters that we don’t have.
7. If we add precipitation_type to all our weather records we should be able to map our numerical weather parameters into one of the eight states with a simple decision tree:

   if precipitation:
       return precipitation_type
   elif wind > SOME_THRESHOLD:
       return 'wind'
   elif visibility < SOME_THRESHOLD:
       return 'fog'
   elif cloud_cover >= 75:
       return 'cloudy'
   elif cloud_cover >= 25:
       return 'partly-cloudy'
   return 'clear'
   

8. The precipitation type is available in all source types:
   1. Derived from “significant weather” (ww) in the MOSMIX data,
   2. As formOfPrecipitation in the SYNOP data,
   3. As present_weather in the current data,
   4. As WWTR in the recent/historical precipitation data.
9. The WWTR field is set to null every third hour in the recent/historical data (which is explained as “following SYNOP standard” but seems odd because it is available in the current data), we will need to come up with a “fill from previous/next hour” logic and clearly document that this field is not taken 1-to-1 from the raw DWD data.

I’m hoping to make significant progress on this tomorrow but don’t wanna promise too much.

@mweinelt @EricMc1289 How annoying is the merging of clear-day and clear-night into clear for your use cases?