NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
> > > Once > > > I've reach a leaf node of the VisAD data object, I then define a netCDF > > > variable that uses the chain of DataAccessors to access the data values. > > > > This won't necessarily work for me; FITS objects can't really be that > > complicated. > > Who's to say that the VisAD data object that's handed to the FITS > "backend" is really a FITS object? It could have come, for example, > from importing a netCDF dataset. In designing the netCDF export > capability, I tried to get away from assuming that the structure of the > VisAD data object that was being exported was going to be the same as > the structure the netCDF backend created on import. Well, since I'm talking about saving to a FITS file, I can safely say that I need to worry about what kind of data I can stuff into a FITS file. Maybe I misunderstood your initial statement. FITS is basically a flat format ... I need to write out either N-dimensional arrays of homogeneous data or 2D (or possibly 3D) tables of heterogeneous data. I assumed that using the *Accessor classes would result in a hierarchical view of the data. If that's the case, it's not very useful for me, since I'd still have to break it down into something that can be saved as a FITS file. (I'm just about to dive into the whole *Adapter/*Accessor stuff, so I'll be able to tell soon whether or not it'll work for me...)
visad archives: