Duck-typing our own NEXRAD decoders to Level2File/Level3File — is this fragile?

[thaliamontreux]

Long-time developer (35+ years) working on a Home Assistant NWS alert integration that needs real-time NEXRAD data without pulling in heavy dependencies. I wrote a native decoder for Level II (Message 31) volumes and NIDS Level III products, and deliberately mirrored the public surface of metpy.io.Level2File / metpy.io.Level3File — sweeps, moments, depVals, azimuth/range arrays, the works — so the rest of my pipeline treats native-decoded volumes and MetPy-decoded volumes interchangeably. MetPy remains the fallback for anything my decoder can't handle (partial volumes, unusual compression, weird packet types).

It's working well in production, but I'd love the project's perspective:

1. Are there known edge cases in Level II/III decoding that downstream tools commonly get wrong — fragmented bzip2 blocks, super-res vs. legacy split cuts, elevation-angle quirks — that I should make sure I handle?
2. Is duck-typing to the Level2File/Level3File surface reasonable, or is there a more stable interface you'd recommend targeting?
3. If I run into format quirks my decoder handles that MetPy doesn't (or vice versa), would a write-up or issue be welcome?

Appreciate any pointers — and thanks for maintaining MetPy, it's been the reference implementation I checked every design decision against.

[PSVedant]

hey thaliamontreux. i would like to contribute my solution to this issue. let me know if i can help.

[thaliamontreux]

Yes plz

…

On Sun, Nov 8, 2026, 10:25 AM Pinayur Sridhar Vedant < ***@***.***> wrote: *PSVedant* left a comment (Unidata/MetPy#4199) <#4199 (comment)> hey thaliamontreux. i would like to contribute my solution to this issue. let me know if i can help. — Reply to this email directly, view it on GitHub <#4199?email_source=notifications&email_token=AVCVAMTGQKLBCW6QBLD6YGT5YCM55A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTMNZSGM4TOOBXGY32M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-6723978767>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AVCVAMSKZF5E6SAXSVA7JDT5YCM55AVCNFSNUABDKJSXA33TNF2G64TZHMYTIMBZGYZDCO2JONZXKZJ3GYZDAOJVG4YTSNJWUF3AE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[PSVedant]

okayy. working on it :))

[PSVedant]

I find the approach of keeping the native decoder compatible with MetPy while retaining it as a fallback quite interesting. It seems like a practical way to reduce dependencies without sacrificing support for less common radar formats.

I'm curious, did you find maintaining compatibility with MetPy's interface more challenging than handling the actual decoding edge cases?

[thaliamontreux]

It was a little challenging I was adding more decoding features to be able to isolate anomalous propagation, when the radar starts showing false rotations anomalous propagation is able to determine whether the radar is experiencing it or not and then able to isolate and reject fake rotations, we're building a system over here that is able to find tornadoes in the process and also being able to decode everything that's useful towards our goal was added because it was needed. Anomalous propagation sucks when you have to deal with it and isolate it. We run a system called home assistant here and I built a module called nwws for it, we get feeds from nwws but at the same time we need radar data and while I was developing it recommended MetPy, when I started to notice that there were a lot of decodings that were not available yet on the module I decided to start making it able to decode more information from the radar streams in their buckets. I was successfully able to decode all the useful ones that would be able to accomplish my goal, basically what I built from the module is a full system that's able to track Nationwide weather, be able to figure out which direction is going and be able to give alerts whether it's going to rain lightning storms coming or any other weather scenario and be able to alert us over our speakers as it approaches, and then we have it also do advanced alerts for severe weather. Our HAOS module developed off of MetPY can also track lightning, and alerts being issued to counties and it also has the ability to track movements of warnings and determine if we're going to fall in that category based on the weather at the time and the direction it is heading. We're able to monitor same and nws alerts and it plots a whole entire grid across America made up of those boundaries

…

On Tue, Nov 10, 2026, 1:21 AM Pinayur Sridhar Vedant < ***@***.***> wrote: *PSVedant* left a comment (Unidata/MetPy#4199) <#4199 (comment)> I find the approach of keeping the native decoder compatible with MetPy while retaining it as a fallback quite interesting. It seems like a practical way to reduce dependencies without sacrificing support for less common radar formats. I'm curious, did you find maintaining compatibility with MetPy's interface more challenging than handling the actual decoding edge cases? — Reply to this email directly, view it on GitHub <#4199?email_source=notifications&email_token=AVCVAMVI4EPDCUACWAKIDNT5YK6XXA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTMNZWGE2TENBZGQ3KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-6761524946>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AVCVAMUVXF6JHPDUQDXG6ZL5YK6XXAVCNFSNUABDKJSXA33TNF2G64TZHMYTIMBZGYZDCO2JONZXKZJ3GYZDAOJVG4YTSNJWUF3AE> . You are receiving this because you authored the thread.Message ID: ***@***.***>