Module Design

[mgrover1]

Let's think about the design!

We would like users to be able to use the following:

import xarray as xr
import xradar

ds = xr.open_dataset("some_radar_data.nc", engine="xradar")

This would return a datatree, with a tree which contains datasets.

We should use the xwrf package as an inspiration here - https://github.com/xarray-contrib/xwrf, which uses a similar approach and API design.

The general xradar reader here would contain the different formats within it (ex. ODIM_H5, CfRadial1, CfRadial2).

General API

One decision we need to make is whether we should make functionality:

• Read + return an xradar object (ex. calculate_kdp(xradar) --> xradar)
• Operate on the xradar dataset (ex. xradar.kdp())

[kmuehlbauer]

@mgrover1 The loading would not work as long as xarray does not adopt datatree unfortunately. Currently we would need to employ datatree functionality directly or to begin with just return a specific sweep.

[mgrover1]

@kmuehlbauer I think we can do this with the existing datatree API, so it might look like

import datatree as dt
import xradar

ds = dt.open_datatree("some_radar_data.nc", engine="xradar")

We would just need to make sure the backend API is configured to support this

[kmuehlbauer]

I'll try this, but there might be more involved with the Backend API. The thing is, the backend API is relying on getting back single groups from files by calling open_dataset multiple times . With cfradial1 there is only one call to open_dataset. Not sure, if it makes much sense to replicate the multiple open approach for cfradial1 files. Anyway, thanks for the suggestion, I''ll definitely have a look that way.

[kmuehlbauer]

@mgrover1 Ah, and we would need to make datatree work with other engines...

https://github.com/xarray-contrib/datatree/blob/main/datatree/io.py#L55-L60

[mgrover1]

@kmuehlbauer - what would you think if we redesigned the model module? Right now, it has a collection of helper functions, but each backend/tree needs to put together its own implementation of it; what if we created a main xradar object, that we used in each of the IO modules, as well as submodules?

This object would then have the other methods associated with it (ex. get_x_y_z

ex.

dt= Xradar()

This would also allow us to add special indexing functionality and such (allowing things like dt.isel(azimuth=0)) which is not currently possible since it is not one of our dimensions.

[kmuehlbauer]

You mean like a class wrapper around xr.Dataset? Hmm, how would we get a sweep dataset out of it? Or do you mean accessor based? I think I'm missing something.

[mgrover1]

I think a wrapper around the datatree...

[kmuehlbauer]

Ok, I can't imagine that right now, but we can try several things. Not bound to a single solution.

[mgrover1]

I can draft something up :)

[jfigui]

Hi,
Personally I favor kdp(xradar) as an approach. Less magic.
Cheers,

Jordi

[kmuehlbauer]

I'll close this for now. The API has settled a bit and we've adopted own open_engine_datatree - functions. These still need to be aligned with xarray.open_datatree, though.