> > We've thought more about the first option than the second because:
> > option one would also be valuable outside the VisAD community; and
> > with option two, the use of attribute conventions would have to be
> > added instead of taking advantage of the netCDF conventions already
> > in the VisAD netCDF adaptor.
> I agree about the first option. As long as VisAD uses the Java NetCDF
> library, and DODS provides the mechanism to extend these classes with
> ones which would, when needed use DODS access, it would allow anyone
> with an app that uses NetCDF to use DODS -- just like in the C and
> Fortran world, right? That would seem to be the all-around best
> (One of the reasons I would not want to make a DODS VisAD adapter is
> that there is a lot of 'magic' (read: hard work) that Steve Emmerson did
> in the NetCDF adapter to turn the metadata into the proper MathTypes in
> VisAD and make Data objects that are directly usable. It would seem the
> same kind of work would be needed to convert a DODS data object, as
> Does someone see this differently?
well of course i see it differently :^}
It seems to me that the problem is that the netcdf API is not high level
enough for what we want to acheive (eg create visad objects with
that match the data). I suspect DODs isnt either, but im not sure.
i dont see how you can adequately represent the data semantics unless
you are parsing something like a netcdf Convention, but perhaps I'm
something. it seems like the problem must be compounded if you
try to map DODS to netcdf (partly because the two APIs have some
One solution that keeps coming up for me is to create pluggable semantic
parsers specific to various datasets and/or Conventions. Also create C/
Fortran/Java data APIs for the data _writers_, and get away from
specifying things at the netcdf attribute level (we will still need
but most users would prefer a higher level API).
I plan on looking at DODS (and ADDE) more closely so I can understand
better with respect to these issues. Any pointers appreciated.