File Reader Support

[josephhardinee]

So I have a few different file formats I was going to add to pyart. They are mostly based around netcdf, but each with it's own 'flavor'. I was thinking of just adding an aux_readers submodule to the io directory to put these in as they are probably less common and usually fairly radar specific. In particular I was looking to add the D3R netcdf versions(multiple), casa netcdf, and CHILL X-Band netcdf versions.

Would this be the preferred way, do you have a different preferred way, or would you rather this specific of reader not be included?

[swnesbitt]

+1 for D3R’s various flavors.

On Jun 11, 2014, at 3:24 AM, Joseph Hardin notifications@github.com<mailto:notifications@github.com> wrote:

So I have a few different file formats I was going to add to pyart. They are mostly based around netcdf, but each with it's own 'flavor'. I was thinking of just adding an aux_readers submodule to the io directory to put these in as they are probably less common and usually fairly radar specific. In particular I was looking to add the D3R netcdf versions(multiple), casa netcdf, and CHILL X-Band netcdf versions.

Would this be the preferred way, do you have a different preferred way, or would you rather this specific of reader not be included?

— Reply to this email directly or view it on GitHubhttps://github.com/ARM-DOE/pyart/issues/161.

Steve Nesbitt Associate Professor Department of Atmospheric Sciences University of Illinois at Urbana-Champaign Urbana, IL 61801-3070 USA voice : +1.217.244.3740 fax : +1.217.244.1752 e-mail : snesbitt@illinois.edumailto:snesbitt@illinois.edu research web page : http://publish.illinois.edu/snesbitt

[jjhelmus]

I like this idea. Basically I can imagine having two "classes" of read function, those that work with the pyart.io.read function for common file formats and another set which need to be explicitly called using pyart.io.read_foo or even pyart.io.aux_readers.read_foo for less common formats. The code for reading these less common formats would be allowed be have additional Python dependencies, looser standards, few or no unit tests and in general be less polished than those in "full support" class. Does this seem reasonable? If so I would suggest moving the read_gamic function to the second class since it requires h5py and isn't detected using the read function.

[josephhardinee]

I've submitted a PR for this #164 . I'll close this and all further discussion should take place there.