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.
NOTE: The netcdf-hdf mailing list is no longer active. The list archives are made available for historical reasons.
> From owner-netcdf-hdf@xxxxxxxxxxxxxxxx Fri May 15 15:48:37 1992 > Date: Fri, 15 May 1992 16:42:13 EDT > From: "Lloyd A. Treinish" <lloydt@xxxxxxxxxxxxxx> > To: hdf-netcdf@xxxxxxxxxxxxx > Cc: goucher@xxxxxxxxxxxxxxxxxxxx > Subject: CDF, netCDF and HDF > > A second issue is data structure residency and how it is supported. For > scaling to any reasonably interesting data set by size, structure and breadth > (i.e., number of parameters/variables/fields), data structures must be disk- > resident and have a built-in caching mechanism appropriate for those > structures. Both CDF and netCDF attempt to do this. In addition, > transaction- > like operations on data must be supported. In other words, the ability to > query, update/modify, delete data in-place is required. If a substantial > investment in building a large data set is made, it is too expensive to make > updates via copying. If I am current in my knowledge of the netCDF and CDF > implementations then this is supported in CDF and not in netCDF. In the HDF > case none of these ideas apply because the data structures are memory > resident. Well, in netCDF, you can "query, update/modify, delete data in-place" as required. You can change the value of attributes. What you can't do, without copying, is change the "shape" of the netCDF once it has been defined.
netcdf-hdf archives: