Custom Query (125 matches)


Show under each result:

Results (10 - 12 of 125)

1 2 3 4 5 6 7 8 9 10 11 12 13 14
Ticket Resolution Summary Owner Reporter
#55 fixed specify that CF uses UDUNITS-2 cf-conventions@… jonathan

Unidata has released a new version of the udunits package, which fixes some problems in the original version. Although the units supported are very largely the same, CF should specify which version is the reference standard, since there are a few differences. Unidata deprecates the original version. Therefore version 2 should be the CF reference. This ticket proposes to clarify and update the CF standard by

  • Replacing all references to UDUNITS with UDUNITS-2.
  • Replacing all references to udunits.dat with references to the appropriate xml file of UDUNITS-2.

I'm submitting this as a defect, because I don't think it materially affects the CF standard.

Jonathan Gregory

#62 fixed scalar auxiliary coordinate clarifications cf-conventions@… taylor13

This proposal is to clear up some apparent inconsistencies in the description of allowable attributes for auxiliary coordinate variables.

At the beginning of section 6.2 of the conventions, it states:

"In some situations a dimension may have alternative sets of coordinates values. Since there can only be one coordinate variable for the dimension (the variable with the same name as the dimension), any alternative sets of values have to be stored in auxiliary coordinate variables. For such alternative coordinate variables, there are no mandatory attributes, but they may have any of the attributes allowed for coordinate variables."

But in paragraph 4 of Chapter 5 it states:

"The axis attribute is not allowed for auxiliary coordinate variables."

in contradiction to the statement in section 6.2.

Furthermore, according to the definition of a scalar coordinate variable (section 1.2), it is supposed to be "functionally equivalent to either a size one coordinate variable or a size one auxiliary coordinate variable." The only way for this to be possible is for both types of scalar coordinates to include the same attributes. Currently the CF document forbids use of the axis attribute in conjunction with auxiliary coordinate variables, but allows its use for coordinate variables. To make the two consistent, the following change to paragraph 4 of Chapter 5 is proposed:

Replace "The axis attribute is not allowed for auxiliary coordinate variables. Auxiliary coordinate variables ..." by "If an axis attribute is attached to an auxiliary coordinate variable, it can be used by applications in the same way the axis attribute is used in conjunction with coordinate variables. Note that if this attribute is missing, it may still be possible to determine if a particular dimension should be associated with the auxiliary coordinate variable. For example, auxiliary coordinate variables ..."

Note that in Example 5.2, the axis attribute "X" is associated with xc, and if the above change were adopted, the axis attribute could also appear in conjunction with the auxiliary coordinate variable "lon". Would this cause problems?

Also, some folks might misinterpret the paragraph at the end of section 2.4, which states that "The advantage of using a coordinate variable is that all its attributes can be used to describe the single-valued quantity, including boundaries." to mean that this is an "advantage over a a size one auxiliary coordinate variable", when in fact it means an "advantage over *omitting* the scalar variable". I therefore propose rewriting this sentence to read:

"The use of a scalar coordinate variable is encouraged, when appropriate, because the coordinate attributes (including axis attribute and the cell bounds) can be defined to more fully describe the quantity of interest."

#109 fixed resolve inconsistency of positive and standard_name attributes davidhassell jonathan

John Graybeal raised the question of what happens if the positive and standard_name attributes of a vertical coordinate variable are inconsistent according to the definition of the latter e.g. if positive="up" and standard_name="depth", which is defined as vertical distance below the surface, implying that positive is down. Steve Hankin and I discussed this on the CF email list and further by email and phone. We would like to propose the following clarification, which should answer the question without materially changing the convention or invalidating existing data.

Append the following to the last paragraph (beginning "Optionally") of introductory part of Section 4.3 (before Section 4.3.1):

If both positive and standard_name are provided, it is recommended that they should be consistent. For instance, if a depth of 1000 metres is represented by -1000 and positive is up, it would be inconsistent to give the standard_name as depth, whose definition (vertical distance below the surface) implies positive down. If an application detects such an inconsistency, the user should be warned, and the positive attribute should be used to determine the sign convention.

Insert the following into Section 4.3 of the conformance document:


The positive attribute should be consistent with the sign convention implied by the definition of the standard_name, if both are provided.

There is no general way to check consistency at present.


1 2 3 4 5 6 7 8 9 10 11 12 13 14
Note: See TracQuery for help on using queries.