Open Elfe opened 2 years ago
Dear @Elfe ,
I just had to figure what I was doing there.
I think my specific reasoning in case of sunshine_duration and similar parameters was:
Now obviously some confusion came up between those two different "setups". From my perspective I'd propose removing those last_1h strings everywhere. Another option would be to add time specs to every parameter but that would include every single one of them.
Do you have further thoughts/ideas on this?
Cheers Benjamin
I think a problem arises from the point values vs. last_1h values. Removing those hints would not be a good thing imho.
Let's say I want to use check temperature for the afternoon at 14:15 then I look at the 14:00 point. Or in better cases try to interpolate 14:00 and 15:00. With last_1h values I would have to check the 15:00 values. All these special cases would need to be glued in extra code :(
Hi again. Sorry for my late answer, have been struggling with some illness.
I understand the point you want to make here: values could be measured instantaneously (e.g. temperature at noon) versus averaged values (average temperature from 11:01 till 12:00). We honestly generally didn't care too much about this otherwise quite important meta information. The DWD has given detailed parameter information capturing used instruments but also information like is a timeseries constructed of instant values. They still name those parameters equally e.g. air temperature etc. We have omitted those information to prevent further splitting of parameters (e.g. temperature_air_instant_200).
Here are some other notes on behalf of your concerns:
What are your opinions on that?
cc @meteoDaniel @amotl @wetterfrosch
@Elfe should we once again elaborate on this? we may also have a small call.
annual update: @Elfe would you want to discuss the parameter naming again? I'm hoping to hear from you
Describe the bug Mosmix data provides values for the current time or for the last x hours. Some returned parameters include this information while others do not. (I just checked the _s data) wind_gust_max_last_1h would be ok while others like sunshine_duration should have a last_1h radiation_global should have a last_1h (tx, tn need a last_12h)
Expected behavior There should be a clear naming scheme for parameters. nice_name_current or nice_name_now nice_name_last_1h or return the mosmix names
Desktop (please complete the following information):
Additional context Renaming could break existing installations.