Upendra,
There is also a document "Developing Conventions for NetCDF-4", no doubt
in need of some updating, that describes why it's wise to wait for the
crystallization of community best practices and experience before
proposing new conventions that haven't been used yet:
http://www.unidata.ucar.edu/netcdf/papers/nc4_conventions.html
--Russ
> 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#id2
> 859830)
>
> 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
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Fri Apr 01 2011 - 11:06:01 BST
