Confusion with io function names

I was trying to read IRIS data with (<- worked okay), then convert it to OPERA ODIM_H5 with (<- worked okay). To test this I tried to read the newly made .h5 with, engine=‘odim’) and, where neither gave any errors with importing, but all data fields were empty or at least not correctly “unpacked”. But everything seemed okay with the new file while reading it with, where the data was identical to the original IRIS file. So my confusion came from the “odim” word, where I assume with the xarray readers the odim does not necessarily mean OPERA ODIM, while to_odim() description says: Save RadarVolume/XRadVol/XRadVolume to ODIM_H5/V2_2 compliant file.

To avoid this confusion, maybe add the “OPERA ODIM_H5” where necessary to distinguish between the two different encoders/decoders? Or just update the description?

Best regards
Jorma Rahu

1 Like

Dear Jorma,

thanks for asking this. So odim does actually mean ODIM_H5 for the xarray readers, or at least I was thinking that during implementation. I’m a bit worried that reading back the data with the odim readers leaves you with empty/wrongly unpacked data. I’d consider that a bug which should be tracked down. Would you mind opening an issue at the wradlib issue tracker? We will come back here with the solution we’ve found.

One last question: Do you have by chance installed the new xradar package in the same environment? We’ve ported the xarray readers from wradlib to xradar and that might bring some confusion, since the xradar engines have the same names as the wradlib ones, but differ slightly in functionality.


And here is an example of reading ODIM files using xradar


Does the new xradar package come with a new wradlib version? I used 1.16.0 wradlib. Should I update wradlib or is it possible/worth to update just xradar?

That’s somewhat complicated. The idea was to port the needed xarray backends to xradar. Since xradar is based on xarray-datatree instead of wradlib’s own RadarVolume and the first dimension of the Dataset is time for FM301/CfRadial2 there need to be some adaptions on the wradlib side to be backwards compatible to a large degree.

The next wradlib version will have xradar as dependency, so that it relies on the xradar- engines and has those engines removed from wradlib codebase.

The pain point now is, that if both wradlib and xradar are installed in the same environment the xradar-based engines will be preferred (at least xarray is mentioning this when opening a file with one of those engines). So if you are working with wradlib do not install xradar in the same environment until this is resolved. Nevertheless, you are invited to try out xradar.

I really hope that these transitioning problems are acceptable with the bright future ahead.

Thanks for the explanation. This is all fine. I will check the examples Max Grover provided when the new, improved version will be available.
Yeah, whatever the reason was, I was not able to get the same data out with the other ODIM readers than just the old read_opera_hdf() function. But I got my things done at the moment, so a little waiting is fine for me.


1 Like

A post was split to a new topic: Read multiple sweeps into xradar object