Closed swnesbitt closed 7 years ago
Thanks @swnesbitt Hopefully some one can look into this. We are short staffed at the moment so this will be on the back burner for a bit.
I think I may have found the solution, this is a Radx issue -- by default it removes the long range and split cuts from NEXRAD data. By setting the following in a RadxConvert params file, I was able to fix the issue:
///////////// preserve_sweeps /////////////////////////
//
// Preserve sweeps just as they are in the file.
//
// Applies generally to NEXRAD data. If true, the sweep details are
// preserved. If false, we consolidate sweeps from split cuts into a
// single sweep.
//
//
// Type: boolean
//
preserve_sweeps = TRUE;
///////////// remove_long_range_rays //////////////////
//
// Option to remove long range rays.
//
// Applies to NEXRAD data. If true, data from the non-Doppler long-range
// sweeps will be removed.
//
//
// Type: boolean
//
remove_long_range_rays = FALSE;
Then run RadxConvert
as such:
RadxConvert -f KDGX20170430_142255_V06 -outdir . -v -params RadxConvert.params
This was a conscious decision on Radx part when I spoke with Mike D a while back.
Ok, makes sense.
All,
Using the devel branch of pyart - having the issue where pyart is able to correctly count and select sweeps from L2 file from S3 using
read_nexrad_archive
, but when I convert the file using RadxConvert to cfradial, it loads in the entire file, and the elevation data is different, but when counting sweeps withradar.nsweeps
or using theradar.get_*
methods, it finds fewer sweeps than I would expect.For example:
while the cfradial file, which has different elevation angles, biffs:
I don't think Radx is reading the files correctly either, but that is another story for another day...