Skip to content
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

xradar and pyart fillvalue discrepancy when working with ODIM #122

Closed
pavlikp opened this issue Aug 4, 2023 · 6 comments · Fixed by #173
Closed

xradar and pyart fillvalue discrepancy when working with ODIM #122

pavlikp opened this issue Aug 4, 2023 · 6 comments · Fixed by #173
Labels
data-standards Data standard related

Comments

@pavlikp
Copy link

pavlikp commented Aug 4, 2023

  • xradar version: 0.3.0
  • Python version: 3.11.4
  • Operating System: Windows 11

Description

I am trying to convert some RAINBOW RB5 data to ODIM for further processing using pyart (the RB5 volumes can't be imported directly due to the variable number of range bins between sweeps not being supported by the pyart package). Anyway, the export and import both work fine in general, however, there is a problem when filling the missing values using the fillvalue/undetect. Here is a plot obtained from the RB5 volume converted using xradar to ODIM, then loaded and plotted through pyart.

image

The red areas on the plot should be masked, however they show up as areas of high reflectivity.

What I Did

# convert file
datatree = xradar.io.backends.rainbow.open_rainbow_datatree(filepath_start + datetime_str + product + filepath_extension)
xradar.io.export.odim.to_odim(datatree, datetime_str + product + '.h5',source='WMO:11887')

# load new file
radar = pyart.aux_io.read_odim_h5(datetime_str + product + '.h5')

Plot showing the unmasked sweep data.

plt.imshow(radar.fields['reflectivity_horizontal']['data'])

image

My temporary solution

I have modified the lines around:
https://github.com/openradar/xradar/blob/5d6a3b86b94860aaf966b47eedff24b8b61ed566/xradar/io/export/odim.py#L113C29-L113C29

from

val = value.sortby(dim0).values
fillval = _fillvalue * scale_factor
fillval += add_offset
val = (val - add_offset) / scale_factor
val[np.isnan(val)] = fillval

to

val = value.sortby(dim0).values
val = (val - add_offset) / scale_factor
val[np.isnan(val)] = _fillval

as the pyart import seems to expect the exact value that is not transformed to create the mask.

After this change, the plot in pyart seems as expected, with the correct mask:
image

Is this a bug or am I misunderstanding the usage of fillval in the ODIM format?

@kmuehlbauer
Copy link
Collaborator

Sorry for the delay here.

Rainbow does not have a notion of undetect/_FillValue. It has a notion of nodata which is natively coded with zero.

But nevertheless this example revealed a bug in the order of applying the _FillValue. We need to switch the last two lines, otherwise a wrong value is encoded.

val = value.sortby(dim0).values
fillval = _fillvalue * scale_factor
fillval += add_offset
val[np.isnan(val)] = fillval
val = (val - add_offset) / scale_factor

In general it is a major pain point, that several radar data formats only have nodata. NetCDF4-based formats have the inherent _FillValue. ODIM knows _Undetect and nodata.

You can specify _FillValue and _Undetect in the .encoding-dict of the respective moment. If none of those is provided xradar choses a default value (maximum of datatype).

@kmuehlbauer
Copy link
Collaborator

Xref #103

@syedhamidali syedhamidali added bug Something isn't working data-standards Data standard related and removed bug Something isn't working labels Sep 29, 2023
@BerendWijers
Copy link

BerendWijers commented Apr 22, 2024

Hi all,

This 'bug' seems to be still apparent in '0.5.0', any idea if and when this will be patched?

  • OS
    Distributor ID: Ubuntu
    Description: Ubuntu 22.04.4 LTS
    Release: 22.04
    Codename: jammy
  • xRadar version
    0.5.0

Thanks,
Berend

@kmuehlbauer
Copy link
Collaborator

@BerendWijers Please check if #173 fixes your issue. Thanks!

@BerendWijers
Copy link

@kmuehlbauer it does! Thank you!

@kmuehlbauer
Copy link
Collaborator

@kmuehlbauer it does! Thank you!

Great, I'll try to finish #173 and let others have a look there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
data-standards Data standard related
Development

Successfully merging a pull request may close this issue.

4 participants