Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for NEXRAD Level 3 product 176, Digital Instantaneous Precipitation Rate (DPR) #551

Closed
jjhelmus opened this issue Jun 30, 2016 · 14 comments

Comments

@jjhelmus
Copy link
Contributor

Py-ART cannot read NEXRAD Level 3 Digital Instantaneous Precipitation Rate (DPR) files (product 176). They are stored as the Generic Radial Product Format which is not supported by the nexrad_level3.py module.

This product stores data in Generic Data Package packets (packet code 28) which is defined in Figure 3-15c on page 3-132 of "INTERFACE CONTROL DOCUMENT FOR THE RPG TO CLASS 1 USER" RPG Build 13.0, Document Number 2620001T. This packet serializes the data using the External Data Representation (XDR) format, see Appendix E of the above document and RFC 1832.

Reading this data should be possible with the xdrlib module in the standard library

@dopplershift
Copy link

There was some weirdness in the ICD too--MetPy has a working implementation: https://github.com/metpy/MetPy/blob/master/metpy/io/nexrad.py#L2082

@jjhelmus
Copy link
Contributor Author

@dopplershift Funny I was just look at that code 😄

@dopplershift
Copy link

Let me know if you find any issues with it--bugs, docs, whatnot.

@jjhelmus
Copy link
Contributor Author

jjhelmus commented Jun 30, 2016

Adding support for the product is not a high priority but when I get to it I let me know if I find anything.

@dcedgren
Copy link
Contributor

dcedgren commented Feb 6, 2018

Just a note that I ran across this issue wanting to bring in DPR Level-III data into Py-ART. Looked into it briefly and I don't know what I'm doing well enough for me to try to use the Metpy code, and Metpy does not currently appear to have an output function.

So mostly just a quick note to say I'd appreciate support for this if you ever get around to it, or else any recommendations for a (not too technical) alternative.

@scollis
Copy link
Member

scollis commented Feb 13, 2018

@dopplershift : Did you ever provide this in MetPy?

One day we should discuss some bridges between MetPy and Py-ART

@dopplershift
Copy link

We have the decoding working, we just don't have much of a data model around them; very ad-hoc data structures with dicts of dicts of lists of dicts...

@scollis
Copy link
Member

scollis commented Feb 13, 2018

Is the data range-az-el data?

@dopplershift
Copy link

Looks like it, yeah. Here's what I played with in MetPy:

from metpy.io import Level3File
f = Level3File('testdata/nids/KOUN_SDUS84_DPRTLX_201305202016')
f.sym_block[0][0]
f.sym_block[0][0]['components']

Looking over that code, it looks like that ICD was pretty damn sketchy...

@craddockME
Copy link

Hi, have there been any updates on this issue since 2016? Looks like pyART still does not support DPR. I see some code in metpy nexrad.py but I'm not clear if it's a placeholder or working code. Hoping to be able to process the DPR data parameter. Thanks in advance for any info!

@dopplershift
Copy link

As far as I’m aware, the code in MetPy should work (though the interface is hideous). I’m not sure if anyone is using it yet, so there may be a lurking bug or two. Feel free to let us know on the MetPy issue tracker if you run into any problems and we can try to get them fixed up.

@scollis
Copy link
Member

scollis commented Jul 11, 2018 via email

@dcedgren
Copy link
Contributor

I'm taking a look again at being able to use the DPA product. Metpy's implementation appears to be working (it ran without errors for me at least). But as @dopplershift noted the structure is ugly. I have a little time to dig into this next week (#coronavirus) so I'm going to try to rig something together and I'll give it a shot to add basic functionality for this product, likely by using metpy to do the heavy lifting and then just re-wrangle it to be a pyart radar object.

I'm still pretty new to programming and to pyart, so I'm open to comments if anyone feels this functionality should work in a certain way or another.@zssherman

@zssherman
Copy link
Collaborator

Hi @dcedgren, yeah using metpy and adding it as a dependency I think is fine. Really the only comment I would have, but you already mentioned, was conforming or feeding it into pyart radar object, but I can help with that. Whenever you have a basic product, feel free to submit a pull request and I can also answer questions and help get it going.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants