-
-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
inconsistent parameter names for mosmix data #615
Comments
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 |
I think a problem arises from the point values vs. last_1h values. 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. |
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? |
@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.
The text was updated successfully, but these errors were encountered: