Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Option to use fixed angle step in Rainbow reader #75

Open
egouden opened this issue Feb 6, 2023 · 6 comments
Open

Option to use fixed angle step in Rainbow reader #75

egouden opened this issue Feb 6, 2023 · 6 comments

Comments

@egouden
Copy link
Contributor

egouden commented Feb 6, 2023

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
Copy link
Collaborator

kmuehlbauer commented Feb 6, 2023

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
Copy link
Contributor Author

egouden commented Feb 6, 2023

Thank you @kmuehlbauer for the suggestion.

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

@kmuehlbauer
Copy link
Collaborator

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
Copy link
Contributor Author

egouden commented Mar 14, 2023

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
Copy link
Collaborator

kmuehlbauer commented Mar 14, 2023

@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
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants