-
Notifications
You must be signed in to change notification settings - Fork 262
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
Method for storing a volume in which the range gate differ between rays. #252
Comments
As a note, I will be working with NCAR in coming months on CF2.0. This On 3/12/15 2:00 PM, Jonathan J. Helmus wrote:
|
Hi, I propose a quick fix for this one: |
@scollis BTW, anything new on CF2.0? |
Hey @kmuehlbauer and @meteoswiss-mdr ! |
@scollis |
So a CF/Radial 2.0 proposal is out and can be found on Github. There is also a CF/Radial 1.5 as well being maintained in parallel (Which I believe should be out at some point). 1.5 looks a lot like 1.4 with improvements to things like naming and some edge cases that were not handled before. 2.0 looks more like the gamic files in that it uses groups to separate sweeps and allows changes of metadata per sweep. This wouldn't necessarily fix your gates problem, just moves it to the sweep level rather than the file level. 1.4 actually allows for a 1D variable ray_n_gates that stores number of saved gates in each ray. I'm not 100% sure why this was dropped in 2.0. PyART could just implement the ray_n_gates solution (Which I think is what you meant by the 1d nrays part). I assume your actual sampling rate is not changing during a sweep, just the number of gates and possibly initial offset? |
Actually I read some of Jonathon's comments about Nexrad and that would require a 2d array of range, or the CF 2.0 route of splitting up by sweep. I'm not sure there is going to be a purely CF/Radial compliant way of implementing this. I'll bring it up with Mike though and see what can be done. I think adding ray_n_gates to 2.0 goes part of the way towards helping. Supporting CF/Radial 2.0 will require some larger changes to PyART most likely to support the group mechanism. |
Yep. Making Py-ART work with CF 2.0 is doable but is a big change.. And there are plenty of other things we want to tackle.. 1.5 will be our target. We are cutting a release this week (1.9 Picasso) , lets aim to get @meteoswiss-mdr 's proposal moving for Py-ART 1.20, Dali |
Merging with #670 |
Many radars collect volume such that the location of the range gates changes between rays most often between different sweeps. For example some NEXRAD file change to a different gate spacing at high elevation. Currently the CfRadial convention on which the Radar class is based has not manner for expressing a radar volume in which the gate locations vary by ray. A method for expressing and storing such data should be developed and implemented in Py-ART. This should be done in such a manner that the method can be included in or as an extension to the CfRadial format.
The text was updated successfully, but these errors were encountered: