Open-Meteo: Incorrect UV Index categories

[elydpg]

Steps to reproduce

1. Add a location sourced from Open-Meteo
2. Check the hourly UV index forecast and look for a time when the UV index is equal to 8

Expected behavior

It should appear red indicating a "Very High" UV index, in line with the WHO Standard

Actual behavior

It appears orange indicating a "Very high"

Weather source used

Open-Meteo

Breezy Weather version

5.2.4 standard

Android version

12

Device

Samsung Galaxy s10e

Other details

Unlike #1108 I do actually think this is a Breezy Weather bug, as Open-Meteo does not provide any categories with its UV indices.

Acknowledgements

• I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open OR closed issue.
• I checked that my issue is not covered in the Frequently Asked Questions document.
• I have updated the app to version 5.2.4 or later and I can reproduce the issue in this version.
• I wrote my request in English, and any screenshot I attached are also in English (language can be changed from Settings > Appearance), unless my issue only happens with a specific language. I can write in my native language under the English text, if necessary.
• I understand that this app is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY, so I may not get a positive reply to my request, if any at all.

[papjul]

Categories are always calculated on app side, regardless of whether the source provides it.

Open-Meteo has a specificity: it provides non-rounded values of UV. Meaning, that you can end up with an UV of 7.99 that will be rounded to 8, but will be in the lower category.

I suggest we follow the issue in #1108 with any source but Open-Meteo due to this specificity.

[elydpg]

So this might actually be a rounding issue, as Open-Meteo supplies fractional UV indices but the WHO categories are only specified for integer values. Note this Open-Meteo example for Eilat, which has both "High" and "Very High" for UV index 8:

It seems that the categories are defined based on the integer part, while the number itself is rounded. I'm not sure if this is intentional, but I think it makes more sense to round first and then calculate the category. Honestly not sure though 🤷

[elydpg]

Open-Meteo has a specificity: it provides non-rounded values of UV. Meaning, that you can end up with an UV of 7.99 that will be rounded to 8, but will be in the lower category.

yep I just realized this is the issue. Don't know the "correct" way to handle this tbh

[papjul]

Yes, exactly.

We also have the same issue with Météo-France, which only provides max UV index of the day. So hourly UV index is calculated according to a formula which makes us having "slightly lower than 8 but not yet 8" values on hourly chart, but not on daily chart.

[papjul]

No, #1108 is different, they only provide rounded values, and they provide hourly values.

Unrounded values should not exist, but in case we have them, we must provide the correct category for the unrounded values, not for the rounded value IMO.

[elydpg]

Unrounded values should not exist, but in case we have them, we must provide the correct category for the unrounded values, not for the rounded value IMO.

Out of curiosity, what are the categories for the unrounded values? WHO doesn't specify if 7.75 for example should be high or very high

Edit: looking at the code it seems the app uses these:

0 <= index < 3 : Low
3 <= index < 6: Moderate
6 <= index < 8: High
8 <= index < 11: Very high
11 <= index: Extreme

[papjul]

Very high starts at 8.0 on my side, not at 7.01.

I believe that if Open-Meteo has values with decimals, it means that in the way you compute it, you end up with decimals at some point. So if you can find some WHO guidelines about the rounding policy, I will apply it if different than ours. Maybe 7.99 is expected to be truncated to 7.0 for example?

[elydpg]

I couldn't find any rounding information unfortunately. But it seems your rounding convention has precedent: The city of Hong Kong measures UV index with decimals and uses the same rounding convention:

[papjul]

And Hong Kong is where the World Meteorological Organization is located, so I will trust them. Maybe we should show 1 decimal then? Although it still wouldn't fix the 7.95-7.99 case.

[elydpg]

I was thinking maybe truncating instead of rounding, but in any case showing decimals by default isn't so helpful IMO. Unless you do a tap to show detail in say the hourly forecast, but adding that detail in there is a separate issue