Opened 7 years ago

Closed 4 years ago

#109 closed defect (fixed)

resolve inconsistency of positive and standard_name attributes

Reported by: jonathan Owned by: davidhassell
Priority: medium Milestone:
Component: cf-conventions Version:
Keywords: Cc:

Description

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

Change History (10)

comment:1 Changed 7 years ago by taylor13

Jonathan, Steve, John, et al.,

I support adding the proposed language.

Karl

comment:2 Changed 7 years ago by graybeal

I support this as well, a well-constructed solution. Thanks gentlemen.

comment:3 follow-up: Changed 7 years ago by graybeal

By the way, I have gone through and associated positive directions with many of the variables -- though not just the coordinate variables. I think that such information needs to be expclitly added to the standard_variables, in order to make this change unambiguous. Let me know where to send the list, if you have a use for it.

comment:4 in reply to: ↑ 3 Changed 7 years ago by graybeal

Replying to graybeal:

By the way, I have gone through and associated positive directions with many of the variables -- though not just the coordinate variables. I think that such information needs to be expclitly added to the standard_variables, in order to make this change unambiguous. Let me know where to send the list, if you have a use for it.

Uh, 'added to the standard_names', that is. Sorry!

comment:5 Changed 7 years ago by biard

Looks great to me!

comment:6 Changed 7 years ago by graybeal

Jonathan, there are several positive statements and no concerns expressed for a while. While the suggest was made to add direction to the standard names table, I think that can be handled (if at all) as a separate ticket, at lower priority.

So can you stamp it final?

comment:7 Changed 7 years ago by jonathan

Since no objections were raised within the allowed time period, we can regard this ticket as agreed. (It's a defect ticket - they are accepted if there are no objections.)

Thanks

Jonathan

comment:8 Changed 4 years ago by davidhassell

  • Owner changed from cf-conventions@… to davidhassell
  • Status changed from new to accepted

comment:9 Changed 4 years ago by painter1

This ticket was implemented a few weeks ago, in the draft 1.7 version of the CF Conventions document. The ticket cannot be closed until the conformance document is also updated.

comment:10 Changed 4 years ago by painter1

  • Resolution set to fixed
  • Status changed from accepted to closed
Note: See TracTickets for help on using tickets.