search

Unidata / MetPy

MetPy is a collection of tools in Python for reading, visualizing and performing calculations with weather data.
https://unidata.github.io/MetPy/
BSD 3-Clause "New" or "Revised" License
1.24k stars 413 forks source link

Level3File threshold error #450

Closed ghost closed 7 years ago

ghost commented 7 years ago

When reading a Level3File, the thresholds are, I believe, being read improperly. The first threshold value should be a signed integer, but is (apparently) being read by MetPy as an unsigned integer. file = Level3File(filename) print file.thresholds

Metpy Output: [65216, 5, 254, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]

What I believe it should be: [-320, 5, 254, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]

That first value should be the minimum DBz value * 10.

dopplershift commented 7 years ago

Well thresholds has a lot of different meaning depending on the exact nature of the product, so it's left completely raw as read from the file. Instead, you should look a the map_data attribute on Level3File. This is a function that converts the byte data to floating point values, using the method that is appropriate for each of the (many) NEXRAD product types. So for a reflectivity product, you can do:

f = Level3File(filename)
print(f.map_data(2))

and it prints -32.0.

Or did you have some other need for thresholds?

dopplershift commented 7 years ago

Having said that, it would be pretty trivial to change to signed.

ghost commented 7 years ago

Ahh, ok. The only spec I was able to find is here: http://weather.unisys.com/wxp/Appendices/Formats/NIDS.html and it's not very descriptive. So it's not clear to me whether or not the threshold values are supposed to be signed. In either case, I was unaware of the map_data function, so that solves my immediate problem. As for whether or not to make the values signed, I'll leave that up to you guys. Personally, I'd follow the spec (if we actually know what the spec is) but I'm happy either way. Thanks for writing great software -- I appreciate it.

On Fri, Jun 9, 2017 at 6:35 PM, Ryan May notifications@github.com wrote:

Having said that, it would be pretty trivial to change to signed.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Unidata/MetPy/issues/450#issuecomment-307515415, or mute the thread https://github.com/notifications/unsubscribe-auth/Aai5u0FT-2EHpztgXMIE337688xGS9Rtks5sCcipgaJpZM4N1SRQ .

--

Jeremy Reed Data Architect

www.climacell.co Follow @WeatherRevealed on Twitter https://twitter.com/weatherrevealed! Stay ahead of the weather - subscribe https://www.climacell.co/subscribe!

dopplershift commented 7 years ago

Thanks for the kind words and reporting the bug (even if it wasn't)--we do appreciate it.

The actual NIDS spec isn't much more specific regarding the types thresholds themselves, though most other header values are listed as signed integers--and many of those are currently handled my Level3File as unsigned. The rationale behind that was because those fields really only make sense as unsigned, but as I revisit that decision today, I lean towards following the letter of the spec (since given the valid range it shouldn't matter) until I have reason to do otherwise.

I'll leave this open as a reminder to do so.