John Caron wrote:
Im not sure what you get from the GRIB IOSP, it uses an RAF in the usual way.
I'm referring to the concept, not the implementation, of providing
access to other data formats via a single interface as opposed to just
wrapping an existing NetCDF file. "One interface to bind them" I seem to
recall. I'd hate to limit that to files.
Giving an IOSP access to the NcML JDOM is probably ok (im not totally sure). Im
not sure how much of the NcMLReader machinery you can take advantage of. You do
have to be careful of pushing a technolgy into places it wasnt designed for. I
should probably look at you NcMLReader$NcMLNetcdfFile mods to see if they can
be added to the base.
NetcdfFile has a constructor that seems to be used only by the
NcMLReader. I simply added an argument to pass in the netcdf
jdom.Element. The NcMLReader$NcMLNetcdfFile constructor is likewise
modified so it can pass the Element on via the super constructor. I also
added a getNetcdfElement() method to NetcdfFile. Unless there is
something else using this constructor, I see no way for there to be any
adverse side effects. At worst, there may be some confusion over why
NetcdfFile has a getNetcdfElement() method.
I'm not fond of exposing this in NetcdfFile. I hoped to completely
encapsulate this within the NcMLReader, but NcMLReader$NcMLNetcdfFile
being "private static" eliminated any other options I could think of.
Doug
