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
