Getting DWD MOSMIX temperature values in degrees Celsius with option `--si-units=0`

[darian-heede]

Describe the bug For DWD MOSMIX cli requests the option si-units=0 doesn't seem to work. The result set still contains temperatures in Kelvin.

To Reproduce The following will reproduce the issue:

docker run -i ghcr.io/earthobservations/wetterdienst-standard wetterdienst values \
  --provider=dwd \
  --network=mosmix \
  --resolution=small \
  --coordinates=49.9195,8.9671 \
  --rank=5 \
  --parameter=small \
  --si-units=0 

Expected behavior I expect the temperature values to be in degrees Celsius when the option si-units=0 is set. I would also expect the default value, i.e. when the option is omitted, to be non scientific units.

Additional context The DWD observations network (recent) works as expected when passing the option:

docker run -i ghcr.io/earthobservations/wetterdienst-standard wetterdienst values \
  --provider=dwd \
  --network=observation \
  --parameter=climate_summary \
  --resolution=daily \
  --period=recent \
  --date=2022-08-29/2022-08-31 \
  --coordinates=49.9195,8.9671 \
  --rank=5 \
  --si-units=0

Acknowledgements Thank you for this amazing project!

[gutzbenj]

Dear @darian-heede ,

regarding the DWD Mosmix output temperature-related data is actually given in Kelvin [1] e.g.

<MetElement>
<ShortName>TTT</ShortName>
<UnitOfMeasurement>K</UnitOfMeasurement>
<Description>Temperature 2m above surface</Description>
</MetElement>

Regarding the default unit setting, as with all other aspects of the library we want to generalize all incoming data and provide a common structure which was the reason to set default units to SI units thus returning e.g. temperature data in Kelvin regardless of where the data comes from. Still though you can use the setting as intended to get non-SI units (for some of the provided data this will be °C).

Does this fully answer your questions?

Cheers Benjamin

[1] https://opendata.dwd.de/weather/lib/MetElementDefinition.xml

[amotl]

Dear Benjamin,

doesn't Wetterdienst already have a unit conversion subsystem in place somewhere? If so, would there be a way to make it support the DWD MOSMIX module?

In any case, I don't think we have a corresponding command line argument for that yet. It would be sweet to have one, but I am unable to come up with an appropriate name.

Maybe my idea is complete nonsense at all. If so, please tell me.

With kind regards, Andreas.

[gutzbenj]

Dear @amotl ,

we already have unit conversions via a unit mapping and some smaller logic available for all services. This is also made available with the si_units=True argument. See also https://github.com/earthobservations/wetterdienst/blob/99b34e9db91bfe3c9707304b8e854f311082cd9f/wetterdienst/ui/cli.py#L556

[amotl]

Thank you. I've just used the snippet provided by @darian-heede and tried different variants of the --si-units parameter. --si-units=0, --si-units=1, and omitting it. It looks like the temperature values in the response are always in Kelvin, so he may have a point here?

[gutzbenj]

He has no point in this because Kelvin as of now is the target unit for temperature values returned by wetterdienst.

With other words Mosmix temperature values originally have Kelvin as unit and we want to convert temperature values to Kelvin when si_units=True which in the case of Mosmix makes the converted temperature values equal the original values, simply because the original values are already given in the unit we assigned to be the target SI unit^^

[amotl]

I understand now, thank you for clarifying. If one would like to see temperature values in °C, this would be up to "userspace" then? Out of curiosity, is there a recipe how would one accomplish this task most conveniently?

[gutzbenj]

Currently this is not possible, however to allow the users to define their own SI/target units, we will have to apply some changes:

• Currently I have set the SI Units in order of their unit but not their field e.g. SIUnit.KELVIN instead of SIUnit.TEMPERATURE. We will have to change them accordingly giving each parameter kind e.g. temperature its own SIUnit
• We will have to make sure that units can be parsed from strings so that users won't have to use the rather nasty methods of pint to define new units.
• For certain parameters, which are not directly convertible - such as precipitation - we will have to make sure that the target units can't be changed or can only be changed in strict manner so that our logic still works. The logic in those cases is to define the conversion factor based on a fixed relation of origin and traget unit.

[darian-heede]

Thank you @amotl and @gutzbenj for the discussion here. From what I gather, the si-unit flag currently works as follows:

• If the source data is not returned in SI units, setting si-units=1 will convert values to scientific.
• If the source already returns metrics in SI, setting si-units doesn't change anything.

If we have the latter case, as with DWD MOSMIX, or want any other units of measurement for the values, the conversion to the therefore lies with the user.

Is the conversion to a fixed set of units something to consider in future?

[gutzbenj]

Dear @darian-heede ,

yep, we have defined for each parameter the original unit and the target unit/SI unit from which we get the conversion factors. If they are same obviously we won't see any changes after the conversion.

Allowing the users to set their own target units in the future is favorable because we don't know what kind of system they are working with. At least for certain units such as temperature units it is also no big deal using pint [1] as common operations are supported directly. More special units such as precipitation (mm -> kg / m2) have to be handled more carefully and will have to be set more strictly e.g. only few options are allowed. For other units such as dimensionless we should disable changing them at all.

[1] https://github.com/hgrecco/pint

[darian-heede]

Thank you @gutzbenj, sounds good.