Combine radar sweeps into a logical radar volume.

[egouden]

This is useful for stacking single sweeps or creating a new volume logic based on time.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.57%. Comparing base (727434c) to head (71bef80).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #307      +/-   ##
==========================================
+ Coverage   93.50%   93.57%   +0.07%     
==========================================
  Files          27       27              
  Lines        5587     5635      +48     
==========================================
+ Hits         5224     5273      +49     
+ Misses        363      362       -1     

Flag	Coverage Δ
notebooktests	0.00% <0.00%> (ø)
unittests	93.57% <100.00%> (+0.07%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[egouden]

I added the option to select sweeps by angle. This is useful if you want to discard a calibration scan (i.e. 90 degree).

[egouden]

@kmuehlbauer

I found inconsistencies in the global variable sweep_group_name. Should it be a list of strings or ints? Most readers return ints but cfradial1 reader returns strings. There is also a conversion in the global metadata constructor.

I think the string is better because it is consistent with the variable name and you can use it directly for accessing the sweeps. I guess this has no negative impact on the performance.

[egouden]

np.datetime64 is now used internally to avoid local time issues

[kmuehlbauer]

@egouden This is a nice addition. I've added a couple of comments.

[kmuehlbauer]

@egouden This will strip any fractions of seconds. I've checked with Manual on Codes, Volume I.2 – International Codes, Annex II to the WMO Technical Regulations, Part B – Binary Codes, Part C – Common Features to Binary and Alphanumeric Codes, WMO-No. 306 and found that time_coverage_start/time_coverage_end is somehow ill-defined (string where it should be double).

Variable path/name	Dimensions	Type	Comment
/time_coverage_start		string	UTC time of first ray in file

but

Variable path/name	Dimensions	Type	Comment
/sweep_/time	(time)	double	Coordinate variable for the time dimension. Each value is the time at centre of each ray.

Both have mandatory attributes as:

Variable path/name	Attribute	Kind	Value
/sweep_/time	units	string	“seconds since ” where is an ISO8601 time string of the form YYYY-MM-DDThh:mm:ssZ
	calendar	string	See CF Conventions Appendix A
	standard_name	string	“time”

So this seems like a flaw in the standard. Not sure how to go from here.

To get this functionality in (and as we still have proper sweep-times), would you mind adding a note on this in the code, so that we do not forget about it, @egouden? Thanks!

[kmuehlbauer]

I've contacted WMO to sort this out. Coming back, if there is some update.

[kmuehlbauer]

@egouden Please add an entry to history.md. After that, it's good to merge.