Issue with reproducing example using NEXRAD

[xebadir]

Have found the code for this very intuitive and a nice implementation of several algorithms that are otherwise hard to come by. I went through the process of implementing this in a script I use which retrieves NEXRAD from the AWS store - and came across a potential issue that others might encounter - namely the assumption that the radar.get_azimuth(0) will represent the rays throughout the sweep elevations. In post 2008 NEXRAD, sweeps for the lowest 3-6 layers are super-res and hence have double the number of rays than those above that layer owing to the enhanced 0.5 degree resolution, leading to the script for MESH or others bailing out. Will provide a worked reproducible and suggest a potential fix - but curious if anyone has implemented a fix for this.

[joshua-wx]

Hi John, Thanks for raising this issue - I haven't come across it before. It certainly impacts the mesh_ppi script. Does it impact other scripts? If you can provide a solution and example volume + test notebook that would be great. I'll also look at adapting it for other retrievals if needed.

[joshua-wx]

This is also becoming an issue for some Australian radars too which have a gate start that changes between sweeps. I'm going to remove pyart as the odim read function and move to using pyodim https://github.com/vlouf/pyodim We developed this tool internally to resolve issue like this.