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.
Bill Weibel writes: > > A major conceptual difference between these two approaches is that > znetcdf defines a new filetype, whereas HDF files containing compressed > objects are still defined as HDF. > > A "compressed variable" approach could be applied to NetCDF, thus avoiding > a new *DF type. Perhaps the relevant compression parameters could be stored > as attributes, such as 'compressed = "true";' and 'compression_factor = 5;'. > Global atts could hold default parameters, while variable atts would hold > settings for individual variables. > Bill -- It is another file type but it is really a wrapper around the normal netCDF file that provides an index into the compressed file. It provides a fairly transparent way of reducing the size of the netCDF files. I would like to see the UCAR netCDF format extended to include this as a variant and compressed and uncompressed files can co-exist with no user intervention. HDF files containing compressed objects need to (and allow you to) explicitly define what variables are compressed and how they are compressed. Data needs to be added to variables all at once or sequentially (for unlimited dimensioned variables) one record at a time. The data cannot be altered in place. My routines compress the whole file but still allow data to be altered and added in place. I think that it uses an approach that is both simpler and more limiting. If you need the flexibility that HDF provides, go with that format. If you are using netCDF and want to reduce the file size, try the new znetcdf library. > > P.S. At least twice now, I've seen the NetCDF magic string referred to as > "CDF1"*, yet in the actual files, the value is "CDF\001". > Does anyone know how this inconsistency got going? > > > *"Graphics File Formats" by Brown and Sheperd, p 400. Good point. I have made this mistake all by my self. I will correct my documentation. The znetcdf magic string is "CDZ\001". --Bill Noon Northeast Regional Climate Center Cornell University
netcdfgroup archives: