Possible bug in Radar.get_gate_area()

[jtcarlin]

When using radar.get_gate_area() applied to archived NEXRAD files, I am seeing a spike in the calculated areas when the azimuth wraps from 359 back to 0 deg. It appears this wrapping is not taken into account when calculating d_azimuths, resulting in an erroneously large d_azimuth.

[zssherman]

@jtcarlin Thanks for the heads up! I'll take a look into this, do you have an example file or datetime for that nexrad archive that I can use for testing?

[jtcarlin]

Thanks for looking into this! I've tried to attach an example file, but just in case it doesn't work, 2022-02-25 at 13:25:14 UTC from KENX is one example (although I've now seen this in multiple cases). Let me know if I can be of any further help looking into this. KENX20220225_132514_V06.zip

[zssherman]

If I understand the code correctly, trying to think would in theory, adding 360 to the diff product work. Example indexed azimuth with the values below gives the -359.5111083984375 value:

azimuths[466] - azimuths[465] (0.2142333984375) - (359.725341796875)

the actual difference is 0.4888916015625

So if we add 360 to that product should give us the same. Thinking the code: diffs[diffs <0.0] += 360 could solve the issue.

Trying to think of scenarios where this wouldn't work...

[jtcarlin]

I think that solution works and is quite elegant! I was going to propose simply adding 360 to all of the azimuths prior to taking the difference to ensure there's no wrapping, which may be equivalent to your solution but unnecessary.

[zssherman]

I'll submit a PR and have it reviewed! Thanks again for raising the issue! Once I get the code in, let me know if the values seem more reasonable. Area max looks to drop from: 721160493.0 to: 1085371.5 with the change.

[mgrover1]

Can we close this? Thanks for submitting that fix @zssherman