Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
tomw wrote: > > Ethan: > > > 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 > solution. > > (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 > well.) > > 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 semantics 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 missing something. it seems like the problem must be compounded if you try to map DODS to netcdf (partly because the two APIs have some impedence mismatch). 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 that, but most users would prefer a higher level API). I plan on looking at DODS (and ADDE) more closely so I can understand them better with respect to these issues. Any pointers appreciated.
visad
archives: