Option to use fixed angle step in Rainbow reader

[egouden]

In Rainbow, the radar measurements can be sampled for a given fixed angle step (fixselect>Anglestep)

It would be nice to have the option to use this as regular nominal coordinates instead of the actual azimuth angles.

[kmuehlbauer]

Thanks @egouden for raising this.

Since xradar 0.0.9 we have angle reindexing implemented. Please have a look here for details here https://docs.openradarscience.org/projects/xradar/en/latest/notebooks/angle_reindexing.html

If you know the layout of your scans, you can read the data like this:

• tolerance: max search distance to next ray for taking into account
• start_angle: sweep start (for 360deg PPI this would be 0)
• stop_angle: sweep end (for 360deg PPI this would be 360)
• angle_res: this would be your fixed angle step
• direction: 1 (clockwise), -1 (counter-clockwise)

reindex_angle=dict(tolerance=1.0, start_angle=0, stop_angle=360, angle_res=1.0, direction=1)
ds = xr.open_dataset(rainbow_file, group="sweep_0", engine="rainbow", reindex_angle=reindex_angle)

So for ray at 0.5deg center-beam the algorithm would take the nearest ray which has a maximum distance of 1.0deg.

Update: python example code, minor fixes

[egouden]

Thank you @kmuehlbauer for the suggestion.

I am wondering if an automatic option based on the file metadata would be interesting.

[kmuehlbauer]

That would be specific to that backend, but we might have the chance to use reindex_angle for that. I'll let this sink in a bit.

[egouden]

I think reading the nominal angles should be the default for all readers for several reasons:

• it follows the philosophy of ODIM and CFRADIAL2
• the actual physical quantity is an azimuth average of about 30 radar beams
• most applications want the nominal angles

• concatenation is easier

  The actual angles (due to imperfection of the radar system) could be read as optional/mandatory metadata (ODIM2.4).

What do you think?

[kmuehlbauer]

@egouden I fully agree to present the dataset in nominal angles.

That's exactly whats angle_reindexing is aimed for. It can actually repair many more issues (missing angles, missing sectors etc). We might retrieve some reasonable default values from metadata to run this without user interaction.

I'd make this either nominal or accurate angles, not both. If a user really want to have both they can retrieve it using reindex_angle itself.

[mgrover1]

Yeah - I agree that setting some reasonable defaults/adding a bit more logic on attempting to calculate some of the fields required would be great!

This is a similar practice to reading in terabytes of climate model output where the exact latitude/longitude can vary a bit. When using open_mfdataset, the file uses the first or last file to use as the coords and aligns everything to that. This is not necessarily what we need to do/follow here, but a similar practice.