To my knowledge CF have so far not of how the conventions will be interpreted
in NetCDF4 files. This is a big subject and it will take a long time to work
through the many innovations in NetCDF4. However, we have recently received a
NetCDF4 file which illustrates a small corner case I would like clarified.
The file is a full NetCDF4 file not NetCDF4-classic (i.e. it does not contain
the hidden HDF5 flag indicating it is NetCDF4-classic). However, it does use a
flat data model and looks almost identical to a classic model file. The one
difference is that it uses NC_STRING as the type of it's string attributes.
E.g.
netcdf4 {
dimensions:
time = 108031 ;
...
// global attributes:
string :Conventions = "CF-1.5 ACDD-1.0" ;
...
}
This file was produced by a recent version of IDL which does not appear to
support the NetCDF4-classic format [1]. In the IDL interface it is possible to
create attributes of type NC_CHAR and be equivilent to arrays of chars in
NetCDF-classic model. However, it is very easy to create attributes of
NC_STRING in IDL so we can expect many further examples of this type of file in
the future.
Strict interpretation of the CF-conventions seem to suggest this file is not
compliant because of section 2.2 of the conventions:
2.2. Data Types
The netCDF data types char, byte, short, int, float or real, and double are all
acceptable. [...]
NetCDF does not support a character string type, so these must be represented
as character arrays. In this document, a one dimensional array of character
data is simply referred to as a "string". An n-dimensional array of strings
must be implemented as a character array of dimension (n,max_string_length),
with the last (most rapidly varying) dimension declared large enough to contain
the longest string in the array. All the strings in a given array are therefore
defined to be equal in length. For example, an array of strings containing the
names of the months would be dimensioned (12,9) in order to accommodate
"September", the month with the longest name.
IMO this section needs to be updated to refer to NetCDF4 in order to remove
ambiguity.
There is a further complication that the current official cf-checker cannot
read this file becauseit cannot handle attributes of type NC_STRING. This sort
of problem is exactly what NetCDF4-classic was intended to mittigate. We can
fix the tool but in the mean time it would help if the CF document was crystal
clear.
I suggest the following options:
1. We state that CF compliant files MUST be NetCDF3 or NetCDF4-classic
format (i.e. "ncdump -k" returns "classic" "64-bit offset" or "netCDF-4 classic
model")
2. We state that CF compliant files MUST only use the types described in
section 2.2 and update the text to make referenct to NetCDF4 types that are not
allowed. A warning about string attributes would be helpful.
3. We state that an attribute with a value of a length-1 array of types
NC_STRING is equivilent to an array of NC_CHAR in CF, and therefore the example
above is acceptable.
Thanks,
Stephen.
[1] http://www.exelisvis.com/docs/ncdf_create.html#netCDF_2618656010_1006152
---
Stephen Pascoe +44 (0)1235 445980
Centre of Environmental Data Archival
STFC Rutherford Appleton Laboratory, Harwell Oxford, Didcot OX11 0QX, UK
--
Scanned by iCritical.
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
