Upendra Dadi <Upendra.Dadi at noaa.gov> writes:
> Hi Folks,
> I am trying to better understand CF model and its relationship with
> netCDF-classic data model. Is there even a relationship? If I am
> creating a netCDF file using CF conventions, does the file have to be
> using classic data model? If I am using netCDF4 with strings and no
> other feature of netCDF4, could it still be CF compliant. Is it right
> to say that one of the basic elements of CF standard is regular
> arrays as opposed to variable length arrays? And that is where the
> "relationship" between CF model and netCDF-classic data model ends?
> Does CF "recognize" variable length arrays?
> I guess these issues are important in the context of proposed discrete
> sampling geometry extension to CF.
>
> Upendra
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Howdy Upendra!
So far, the CF conventions have stuck to the classic netCDF model. That
is, there is nothing in any CF convention that requires (or even
acknowledges) any of the new features of the netCDF enhanced model.
As the CF conventions are written, they seem to imply that one must use
only the classic model. Perhaps the CF conventions just need to be
updated on this point. They say (v 1.5, which I got here:
http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.5/cf-conventions.html#id2859830)
The netCDF data types char, byte, short, int, float or real, and
double are all acceptable. The char type is not intended for numeric
data. One byte numeric data should be stored using the byte data
type. All integer types are treated by the netCDF interface as
signed. It is possible to treat the byte type as unsigned by using
the NUG convention of indicating the unsigned range using the
valid_min, valid_max, or valid_range attributes.
NetCDF does not support a character string type, so these must be
represented as character arrays...
This is incorrect. NetCDF has had a string type since 2008. All integer
types are not signed. (I would also suggest that using a (new) unsigned
type might be preferable to relying on the target software to use the
NUG conventions.)
If the intention is that only the classic model be used, then perhaps
that should be explicitly stated. Users can create netCDF-4/HDF5 files
with the NC_CLASSIC_MODEL flag to enforce the classic model on the data
file.
If someone proposes a CF convention which relies on the enhanced model,
and the associated datasets are of sufficient interest to the CF
community, then presumably the CF standard will adopt some conventions
that require the enhanced model. But even then, most (other) files will
not be using the enhanced model.
On the GRIDSPEC project we (briefly) salivated at the greater
representational power of the enhanced model. But we stuck to the
classic model for maximum compatibility with existing software packages.
Hope this answers some questions...
Thanks,
Ed
--
Ed Hartnett -- ed at unidata.ucar.edu
Received on Fri Apr 01 2011 - 09:57:41 BST
