This message came from the CF Trac system. Do not reply. Instead, enter your comments in the CF Trac system at https://cf-pcmdi.llnl.gov/trac/.
#104: Clarify the interpretation of scalar coordinate variables -----------------------------+---------------------------------------------- Reporter: jonathan | Owner: [email protected] Type: enhancement | Status: new Priority: medium | Milestone: Component: cf-conventions | Version: Resolution: | Keywords: -----------------------------+---------------------------------------------- Comment (by jonathan): Dear all For the sake of clarity, I will restate what we now propose in this ticket. This is the motivation: Scalar coordinate variables provide a convenient way to encode coordinate variables of size one. They do so by borrowing the syntax that is otherwise used for auxiliary coordinate variables. There is, however, a key difference between the interpretation of scalar coordinate variables and auxiliary coordinate variables. Scalar coordinates have the same status in a CF file as (conventional, Unidata, COARDS) coordinates in which the dimension name and the variable name match. These coordinates define the independent variables (spatiotemporal and others) for the data variable. Auxiliary coordinate variables provide extra information as a function of these independent variables, as alternative numeric values (which don't have to be unique or monotonic along a given dimension), or string-valued labels. To indicate that a variable is intended to be an auxiliary coordinate variable, it is necessary to give it a dimension, in order to show which coordinate variable(s) it belongs to. Numeric scalar coordinate variables are not to be interpreted as auxiliary coordinate variables. This is the change to the convention: '''Section 5.7, Scalar coordinate variables.''' Replace 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. with The use of scalar coordinate variables is a convenience feature which avoids adding size one dimensions to variables. A numeric scalar coordinate variable has the same information content and can be used in the same contexts as a size one numeric coordinate variable. Similarly, a string-valued scalar coordinate variable has the same meaning and purposes as a size one string-valued auxiliary coordinate variable (Section 6.1). At the end of the section, add: 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. '''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 string-valued auxiliary coordinate 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 which has not been added to the data variable. This is a convenience feature. Since no new objections or comments have been made for three weeks, and enough support has been expressed previously, I think this ticket could be accepted according to the rules. However, I guess that Mark, for instance, is not content with it. It would be helpful to hear views from others on the proposal as it now stands. Cheers Jonathan -- Ticket URL: <https://cf-pcmdi.llnl.gov/trac/ticket/104#comment:28> CF Metadata <http://cf-pcmdi.llnl.gov/> CF Metadata This message came from the CF Trac system. To unsubscribe, without unsubscribing to the regular cf-metadata list, send a message to "[email protected]" with "unsubscribe cf-metadata" in the body of your message.
