BUG: Fix value mapper for DPR product

dopplershift · dopplershift · commit 8c964b9e6405 · 2022-04-18T20:41:24.000-06:00
One of the threshold blocks had a value of 65535, which got interpreted
as -1--thus breaking our construction of the lookup table.
diff --git a/src/metpy/io/nexrad.py b/src/metpy/io/nexrad.py
@@ -915,8 +915,11 @@ class GenericDigitalMapper(DataMapper):
 
     def __init__(self, prod):
         """Initialize the mapper by pulling out all the information from the product."""
+        # Need to treat this value as unsigned, so we can use the full 16-bit range. This
+        # is necessary at least for the DPR product, otherwise it has a value of -1.
+        max_data_val = prod.thresholds[5] & 0xFFFF
+
         # Values will be [0, max] inclusive, so need to add 1 to max value to get proper size.
-        max_data_val = prod.thresholds[5]
         super().__init__(max_data_val + 1)
 
         scale = float32(prod.thresholds[0], prod.thresholds[1])
diff --git a/tests/io/test_nexrad.py b/tests/io/test_nexrad.py
@@ -138,7 +138,13 @@ def test_level3_files(fname):
     if hasattr(f, 'sym_block'):
         block = f.sym_block[0][0]
         if 'data' in block:
-            f.map_data(block['data'])
+            data = block['data']
+        # Looks for radials in the XDR generic products
+        elif 'components' in block and hasattr(block['components'], 'radials'):
+            data = np.array([rad.data for rad in block['components'].radials])
+        else:
+            data = []
+        f.map_data(data)
 
     assert f.filename == fname
 
