earthobservations / wetterdienst

Open weather data for humans.
https://wetterdienst.readthedocs.io/
MIT License
362 stars 55 forks source link

inconsistent parameter names for mosmix data #615

Open Elfe opened 2 years ago

Elfe commented 2 years ago

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.

gutzbenj commented 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:

  1. the time scale usually should be derived from the resolution
  2. the resolution in general is hourly for Mosmix so a standard parameter would refer to this last hour
  3. you've seen other parameters that have an attached _last_1h which I added because those parameters are given in multiple timescales e.g. last_1h, last_3h, ...
  4. generally speaking I tried not to add too many new parameters but find a general base/set

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

Elfe commented 2 years ago

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 :(

gutzbenj commented 2 years ago

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

gutzbenj commented 2 years ago

@Elfe should we once again elaborate on this? we may also have a small call.

gutzbenj commented 1 year ago

annual update: @Elfe would you want to discuss the parameter naming again? I'm hoping to hear from you