Roadmap for future xradar accessor methods

[ghiggi]

Hi @kmuehlbauer @aladinor @mgrover1 !

I start to dive across the xradar codebase and documentation to develop the ERAD short course tutorials.
I thought to summarize here some thoughts / nice-to-have tools that pop-up in my mind while trying to streamline the tutorials.
I am not sure about if some of these suggestions fall into the scope of xradar or rather should/will be delegated to pyart 2.0, wradlib accessors or some new package. Maybe we could define a roadmap to clarify the future tools provided by xradar

Nice to have accessors
xr.DataArray

• da.xradar.plot (for the azimuth-range or time-range plot)
• da.xradar.plot_ppi
• da.xradar.plot_mesh
• da.xradar.plot_centroids
• ds.xradar.fix_angle

xr.Dataset

• ds.xradar.fix_angle
• ds.xradar.plot_ppi (FacetGrid over variables and/or time)
• ds.xradar.plot_mesh
• ds.xradar.plot_centroids

xr.DataTree

• dt.xradar.plot_rhi (default to FacetGrid over variable and/or time if variable=None)
• dt.xradar.plot_cappi (default to FacetGrid over variable and/or time if variable=None)
• dt.xradar.plot_ppi (FacetGrid over sweep and variables if variable=None and sweep=None)
• dt.xradar.fix_angle
• dt.xradar.cross_section, dt.xradar.rhi, dt.xradar.cross_section`

CRS and coordinates utilities

• dt.xradar.add/get_geographic_coordinates(crs) # i.e. WGS84 --> Add/get (lon, lat, height) coordinates
• dt.xradar.add/get_projection_coordinates(crs) # i.e. planar one --> Add/get (x_c, y_y, z_c) coordinates
• dt.xradar.to_cartopy_crs() # the x,y,z centered on radar?

Related to the CRS, I noticed that the current default CRS is defined as 2D Cartesian with respect to the radar location (x,y).
Why not define it as 3D Cartesian with respect to the radar location (x,y,z)?

Concatenation method

• xradar.concat(dt) # take care of updating time_coverage_start, time_coverage_end, stack radar_calibration, radar_parameters` over time if varying ?
• xradar.concat(ds) # take care of checking attrs, coordinates does not change
  --> Useful for xradar.open_mf_*: open_{engine}_mfdatatree functionality #79
  --> Maybe worth to wait DataTree integration into xarray ?

Access to radar data on cloud buckets
Finally I also start to write some code to access radar data of FMI, NEXRAD and IDEAM on AWS S3 buckets.
I thought would be nice to have a separate 'search' package or module enabling to list all the available radars on cloud buckets (i.e with relevant configurations on YAML files, specify radar, start_time, end_time of interest and being able to

• 1. retrieve a list of filepaths or fsspec file objects,
• 2. obtain directly a xradar DataTree, hiding away to users the need of manipulating filepaths, specify the correct engine/reader, sanitize the xarray object (i.e. fixing angle) and concatenating multiple scan volumes together.
• 3. download the data locally ...

This last idea could be a point of discussion at ERAD to maybe make a prototype or design some standards ...

End of my solo brainstorming 😄

[kmuehlbauer]

@ghiggi Thanks for writing that down. Those are all valid points, which surely should be discussed here or also at ERAD.

Here are my 2c:

From my perspective xradar should have all the bits and pieces to access/read/combine radar data of any provenience. Writing only to standards. There is reasonable plotting capabilities included via xarray in combination with the built-in minimal georeferencing.

Any advanced stuff should be implemented in dedicated packages. This will keep maintenance burden low.

I'm open to move any advanced plotting code from wradlib (wrl.vis.plot) to a new dedicated radar plotting package.