Expand icons a bit?

[poetaster]

A very common case is icon: partly-cloudy-{day,night} condition: rain.

At the moment I'm compensating, but that makes the Icon field useless. Well, icon is basically not so useful?

I'm working on a QT/QML client (first for Sailfishos). https://github.com/poetaster/harbour-dwd

If you don't have the resources, I could produce some mappings, although I'm rather strapped. Um. Where are the mappings?

[jdemaeyer]

Hi @poetaster, thanks for the feedback!

Could you elaborate on how you think the icon field needs to be expanded, e.g. which values you think are missing?

Um. Where are the mappings?

You can find the available icon values in the "Response" sections of Bright Sky's docs:

Field:   icon
Type:    enum | null
Allowed: clear-day | clear-night | partly-cloudy-day | partly-cloudy-night | cloudy | fog | wind | rain |
         sleet | snow | hail | thunderstorm

Bright Sky has inherited these values from Dark Sky and they are also pretty close to what OpenWeatherMap returns.

A very common case is icon: partly-cloudy-{day,night} condition: rain.

At the moment I'm compensating, but that makes the Icon field useless. Well, icon is basically not so useful?

How does your compensation look like? While the condition field is more-or-less coming straight from the DWD, Bright Sky is calculating the icon field from a few of the weather parameters. In particular, like in the case above, it will ignore a DWD rain condition if there is only very little rain (less than half a millimeter per hour).

Are you querying the /weather or the /current_weather endpoint? It's possible that the 0.5 mm threshold is a little too high for /current_weather.

[poetaster]

One case that came up in the past days is: Icon: partly-cloudy-day alternating with cloudy-day Percipitation: ..2mm - .6 mm Condition: rain

This was an alternating, cloudy, sunny, and showers day. Light showers/drizzle. In the app this looked like well, just cloudy, then partly cloudy.

So I mapped this to custom icon with partly-cloudy-day-light-showers . i was representing everything over .2mm to 1mm as light to medium showers. I haven't made a table of value mappings yet, just conditionals on precipitation adding suffixes( showers, light, medium where percipitation > .2mm < 1 mm in the hour). I'm not certain if the case, 95% cloudy, 1mm rain warrants calling it cloudy-day-light-showers, but that's basically what I'm doing.

In a sense it's just a question of granularity. The icon, rain on condition rain doesn't serve well if you have an hour with partly-cloudy conditions and it rains 2 mm in 10 minutes.

SNIP ...BrightSky is calculating the icon field from a few of the weather parameters. these are the mappings/conditionals I was looking for. I'll look at those a bit more closely.

I'm using the weather endpoint. Should I be using current_weather?

I'll build this out in the app a bit more with more granularity, document my values and try to develop a heuristic that could work for you. I'll also make some screen shots on days where the variability shows (today it's too constant, yesterday was good).

Btw, thanks for a GREAT api!

[jdemaeyer]

In a sense it's just a question of granularity. The icon, rain on condition rain doesn't serve well if you have an hour with partly-cloudy conditions and it rains 2 mm in 10 minutes.

Unfortunately we have no way to detect that, all that the DWD data provides is the total amount of rain for a given hour, with no information on how it's distributed throughout the hour.

I'm using the weather endpoint. Should I be using current_weather?

No, you're probably good. The /current_weather endpoint will return the momentary weather as per the latest measurement (based on SYNOP messages, which are publicized more frequently than just every hour), but it won't yield any data for the future or past.

I'll build this out in the app a bit more with more granularity, document my values and try to develop a heuristic that could work for you. I'll also make some screen shots on days where the variability shows (today it's too constant, yesterday was good).

Sounds good! I do not think we can deviate from the current allowed icon values as it'll break existing apps and make it harder to transition from other APIs, but we could add a new field (icon_detailed or icon_suffix or something like that). Plus we can adjust the current icon decision tree if you have a more "realistic" conditions-to-icon mapping =)

Thanks again for the input and the warm words!

[poetaster]

Ok. This is a start, just to illustrate. Sadly, the weather moves and so does the forecast! :) The first image is with a bit of additional primitive logic, using pngs and & the second (about an hour later, and sadly differnt data) is using the mappings given by bright sky (and the font). It's just for an impression (I think it's also a bit confusing that the icons with color discriminate differently than the flat fonts). Between 16:00 -20:00 is of most import.

                    source:
                        if ( model.icon === "cloudy" && parseFloat(model.precipitation) > 0.2 ) {
                            return "../png/showers.png";
                        } else if ( model.icon === "partly-cloudy-day" && parseFloat(model.precipitation) > 0.2 ) {
                            return "../png/partly-cloudy-day-showers.png";
                        } else {
                            return "../png/"+ model.icon + ".png";
                        }

[poetaster]

Here the function that adds a bit more granularity:

function mapIcon(icon,precipitation,condition) {

// condition - dry┃fog┃rain┃sleet┃snow┃hail┃thunderstorm┃
// icon - clear-day┃clear-night┃partly-cloudy-day┃partly-cloudy-night┃cloudy┃fog┃wind┃rain┃sleet┃snow┃hail┃thunderstorm┃

    if ((icon === "partly-cloudy-day"  ||  icon === "partly-cloudy-night") && 
           (condition === "rain" || condition === "snow")) {
        icon = icon + '-' + condition;
    }

    if (icon === "cloudy"  && 
        (condition === "rain" || condition === "snow") && precipitation > 0.2) {
        icon = icon + '-' + condition;
    }

    var iconMapping = {
        'clear-day': '\uf00d',
        'clear-night': '\uf02e',
        'partly-cloudy-day': '\uf002',
        'partly-cloudy-day-rain': '\uf009',
        'partly-cloudy-day-rain': '\uf009',
        'partly-cloudy-day-snow': '\uf00a',
        //'partly-cloudy-night': '\uf083',
        'partly-cloudy-night': '\uf086',
        'partly-cloudy-night-rain': '\uf029',
        'partly-cloudy-night-snow': '\uf067',
        'cloudy': '\uf013',
        'cloudy-rain': '\uf01a',
        'cloudy-snow': '\uf01b',
        'fog': '\uf014',
        'wind': '\uf050',
        'rain': '\uf019',
        'sleet': '\uf0b3',
        'snow': '\uf038',
        'hail': '\uf015',
        'thunderstorm': '\uf01e'
    }
   
    return iconMapping[icon]
}

This screenshot demonstrates. Without the additional logic, all of the icons would have been 'cloudy' in this case/day. Of course, now the sun's shining so it's all misleading :) I love the weather. I've added the % cloud, rain and 'condition' fields to the display for easy comparison.

[poetaster]

Just a note to say I've released a client (pure QT/QML) for sailfishos ... I'm using and updating as conditions (also comparing other data sources) allow. https://github.com/poetaster/harbour-dwd

More data is good.

[poetaster]

I have work arounds in place that satisfy the constraints.