What problem do you want to solve with this change?
Currently, when the weather module converts a C temperature to an F temperature, it rounds to the nearest tenths place. This is awkward for the UI; not every provider offers temperatures to the precision of the tenths place.
If I see something as a whole number, let's say 56F, then I accurately assume that the temperature is +-0.5 degrees of 56F. However, if I see 56.2F from a provider that always returns whole numbers, then I incorrectly assume that the temperature is +-0.05 degrees of 56.2F.
What do you think is the correct solution?
Add a new public readonly property in the classes of the providers. This defines the level of precision offered in the API by the provider. E.g.:
- 1 means that the API returns whole numbers
- 0.1 means that the API returns precision to the tenths place
- and so on (I would imagine you wouldn't go beyond 0.1 for the weather module)
- Alternatively, just specify the number of decimal places
(NOTE: we can't just assume that a provider always uses whole numbers if the API returns a whole number [maybe we happened to have a whole number on that pull]; don't use the API response to determine this)
Adjust the weather module accordingly. When the weather module rounds or converts/rounds measurements, then look at the specified precision. Round accordingly.
Participation
Additional comments
This might apply to precipitation amount, and maybe other data, as well (I'm not 100% sure yet).
What problem do you want to solve with this change?
Currently, when the weather module converts a C temperature to an F temperature, it rounds to the nearest tenths place. This is awkward for the UI; not every provider offers temperatures to the precision of the tenths place.
If I see something as a whole number, let's say 56F, then I accurately assume that the temperature is +-0.5 degrees of 56F. However, if I see 56.2F from a provider that always returns whole numbers, then I incorrectly assume that the temperature is +-0.05 degrees of 56.2F.
What do you think is the correct solution?
Add a new public readonly property in the classes of the providers. This defines the level of precision offered in the API by the provider. E.g.:
(NOTE: we can't just assume that a provider always uses whole numbers if the API returns a whole number [maybe we happened to have a whole number on that pull]; don't use the API response to determine this)
Adjust the weather module accordingly. When the weather module rounds or converts/rounds measurements, then look at the specified precision. Round accordingly.
Participation
Additional comments
This might apply to precipitation amount, and maybe other data, as well (I'm not 100% sure yet).