Custom Query (125 matches)

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:

Recommendations:

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.

Jonathan

Some geophysical quantities, including some vertical coordinates, are defined with reference to the geoid. For example, the standard_name of altitude is the height above the geoid. CF does not have a default geoid, because the convention is used for both model-generated and real-world data, and climate models typically do not use a real-world geoid. When CF is used for real-world data, it may be necessary to desirable to specify which geoid is being used.

This proposal is to define a new attribute geoid_name to be included in the table of Appendix F for the legal attributes of the grid_mapping variable. This attribute will have type S (string) and its description will be "The name of the geoid. Corresponds to an OGC WKT VERT_DATUM name."

​Ticket 80, which was agreed a long time ago for inclusion in CF 1.7, also adds some attributes to Appendix F. This proposal is complementary to and consistent with that one.

Jonathan Gregory

Following a suggestion of Aaron Sweeney, I propose that this sentence in the first paragraph of Sect 3.3 should be amended:

"For some applications it would be desirable to have a more definitive description of the quantity, which would allow users of data from different sources to determine whether quantities were in fact comparable."

to read

"For some applications it would be desirable to have a more definitive description of the quantity, which would allow users of data from different sources (some of which might be models and others observational) to determine whether quantities were in fact comparable."

Since this is a defect ticket, which aims to clarify the convention but not to alter it in meaning, it will be accepted by default unless there is an objection or alternative suggestion.

Jonathan