r Mark and all
As has been discussed in previous emails, David Hassell and I think that
interpreting the CF convention requires only the two concepts of (Unidata or
dimension) coordinate variables and (CF) auxiliary coordinate variables,
whereas scalar coordinate variables are (as the standard says) a convenient
way of representing these two kinds when they have size one, and don't imply a
third coordinate concept, as Mark argues they do. To make this clear, we
propose some changes to the standard document. I've also put this on a trac
defect ticket (
https://cf-pcmdi.llnl.gov/trac/ticket/104), because in our view
it isn't a change to the convention, just a clarification of what was intended.
Best wishes
Jonathan
Section 1.2, Terminology
No change to the definition of a scalar coordinate variable, which is:
"A scalar variable that contains coordinate data. Functionally equivalent to
either a size one coordinate variable or a size one auxiliary coordinate
variable."
Section 5.7, Scalar coordinate variables.
The convention contains the following sentences:
"Under COARDS the method of providing a single valued coordinate was to add a
dimension of size one to the variable, and supply the corresponding coordinate
variable. The new scalar coordinate variable is a convenience feature which
avoids adding size one dimensions to variables. Scalar coordinate variables
have the same information content and can be used in the same contexts as a
size one coordinate variable."
These sentences are OK as they stand, we think, but it would be better to
describe the current situation without emphasising its history, so we would
propose to replace them with the following. In addition, we propose to add a
bit extra, as shown, to the second sentence below:
"The use of scalar coordinate variables is a convenience feature which avoids
adding size one dimensions to variables. A scalar coordinate variable has the
same information content and can be used in the same contexts as a size one
coordinate variable, if numeric, or a size one auxiliary coordinate variable,
if a string (Section 6.1)."
The next sentence would be unchanged; it mentions how this situation relates
to that of the COARDS convention.
At the end of the section, after the example, we propose to append the
following sentences:
"If a data variable has two or more scalar coordinate variables, they are
regarded as though they were all independent coordinate variables with
dimensions of size one. If two or more single valued coordinates are not
independent, but have related values (for instance, time and forecast period,
or vertical coordinate and model level number, Section 6.2), they should be
stored as coordinate or auxiliary coordinate variables of the same size one
dimension, not as scalar coordinate variables."
We think the above interpretation and implications are consistent with the
convention already, which says in this section that, "Scalar coordinate
variables have the same information content and can be used in the same
contexts as a size one coordinate variable". However, it would be an
improvement to spell it out. In this interpretation, we differ from Mark.
Section 6.1, Labels
Replace the last sentence
"If a character variable has only one dimension (the maximum length of the
string), it is regarded as a string-valued scalar coordinate variable,
analogous to a numeric scalar coordinate variable (see Section 5.7, Scalar
Coordinate Variables)."
with
"If a character variable has only one dimension (the maximum length of the
string), it is a string-valued scalar coordinate variable (see Section 5.7,
Scalar Coordinate Variables). As such, it has the same information content and
can be used in the same contexts as a string-valued auxiliary coordinate
variable of a size one dimension. This is a convenience feature which avoids
adding the size one dimension to the data variable."
The last part is a repetition of what Section 5.7 says. The reason for the
change is that the existing wording is careless in implying that a string
could be a coordinate variable; in fact, this is not possible, since string-
value coordinates must be auxiliary coordinate variables.
Mark proposes changes to section 9. We do not propose that yet, because we
think we need to agree on the CF data model for version 1.5, before working
out the interpretation of discrete sampling geometries.
Cheers
Received on Thu Jun 13 2013 - 11:01:54 BST
