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 _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
