Thanks for the issue. This is very doable: xradar data needs be represented in the UGRID framework. This would require defining how the radial coordinates and associated metadata map onto the UGRID concepts.

Initial implementation could extend open_grid and follow style of this reader

Hi @mgrover1

There are a few ways we could handle this, and this is with me making the assumption that the data provided can be easily converted to spherical or Cartesian coordinates.

Triangulation or Tessellation

We could run scipy.spatial.Delaunay or scipy.spatial.SphericalVoronoi to create a UGRID compatible grid. For reference, a minimal grid to be read in using uxarray.Grid.from_topology() requires the following variables

• node_lon & node_lat: The longitude and lattitude of the corner nodes of each cell
• face_node_connectivity: The indices of the nodes that surround each face

Remapping

As part of #892, I can add an option to remap arbitrary coordinate onto a structured grid. This would require the user to provide a destination grid, but makes me lean towards the first option.

Thanks for the quick response @rajeeja and @philipc2 👍

Here is an example of what a plan position indicator (PPI) plot usually look like with proper grid edges defined and plotting with matplotlib
https://arm-doe.github.io/pyart/examples/plotting/plot_ppi_cfradial.html

We currently extract the edges in this function
https://github.com/ARM-DOE/pyart/blob/main/pyart/core/transforms.py#L149

I am not sure if this would help with the triangulation then or if we could feed this manually-defined cell edge information into the function(s) here

Hi @mgrover1 , thanks for the issue!

To make sure I am understanding the geometry the radar data can have correctly: There are point clouds (gate centers?) on arbitrary geolocations (maybe not that arbitrary because of the radar sweeps?), and there are edges that are consisting of pairs of those gate centers, which is already generated by pyart, right? Also, pyart doesn't care about any faces/cells that could consist of groups of those edges, also several gate centers, correct?

In UXarray though, we need faces to be also defined for a grid topology to be represented. We need to know (or generate through triangulation as @philipc2 pointed out) face-to-node connectivity at the least (our "node"s correspond to your gate centers I believe?). Regardless, UXarray will eventually need to generate a grid out of point clouds, i.e. defining faces (most likely triangles through Delaunay) out of point clouds and the face-node connectivity, since this seems to be much needed anyways. In the pyart case though, since you are already generating edges out of points, we'd need to use those edges to generate faces rather than making a simple triangulation of the points disregarding your edges. @rajeeja @philipc2 feel free to correct any points.

If we can do that, I think radar applications can benefit much from UXarray's existing and future edge-based plotting and analysis functions (if I am correct with my above understanding of the radar geometry). I am not sure though if UXarray grids' faces/cells, triangles in this case, can be of any use for analysis (they can still be helpful with visualization funcs like rasterized plots for instance).

Thoughts?