Custom Query (124 matches)

Rich Signell has pointed out an error in the CF standard document by raising a trac ticket. I think we need rules for deciding to make corrections, or there's a danger they might not be implemented. I propose the following:

1. These rules apply to the CF conventions document, the conformance document, the standard name table and its guidelines.

2. Errors in these documents can be corrected under these rules if it is clear that the text as it stands isn't what was agreed, because of a typographical or some other error. These rules can't be followed for making substantive changes. Errors in the standard names can alternatively be pointed out on the CF email list, and implemented by the manager of CF standard names (Alison) as part of a regular update.

3. If someone thinks there is an error in a document, they should open a Trac ticket of type "defect" to point it out and to state what should be done to the text in order to correct the error.

4. The correction is held to have been agreed if three weeks pass without anyone disagreeing with it. After that period, the ticket should be closed by the manager of the CF conventions (Kyle) or the manager of CF standard names (Alison), who will make the change. No moderator is needed because there cannot be any substantive discussion under these rules.

5. If anyone disagrees that the correction should be made, because they think the document does have the intended meaning, then a correction cannot be made by these rules, the ticket should be closed, and the change should be proposed as an enhancement instead, following the rules for making changes to the CF standard, if the proposer wants to pursue the issue.

It feels a bit bureaucratic to have rules, but I think it may be necessary because experience shows that without rules we find it hard to reach conclusions. Please post your comments to this ticket.

Jonathan

This is a proposed correction for an error in the documents, not a change to the standard. According to the rules, it will be accepted if no-one objects to it in the next three weeks.

The table in Appendix A incorrectly states that flag_values is a string attribute. This is inconsistent with CF 3.5, which says, "The flag_values attribute is the same type as the variable to which it is attached." This error was pointed out by John Stark in April 2007 ​http://www.cgd.ucar.edu/pipermail/cf-metadata/2007/001614.html and this month by Philippe Poilbarbe on the netCDF email list.

The correction required is as follows:

• Add "D for the type of the data variable" to the sentence "The Type values are S for string, N for numeric" before the table in Appendix A.

• Change the type from S to D for flag_values in the table.

• In the conformance document, add a section:

  3.5 Flags
  Requirements:
  The flag_values attribute must have the same type as the variable to which it is attached.
  

Jonathan

In example 7.9 of the convention, the variable time_bounds appears but is not needed because the climatology_bounds are defined. Note that there is no "bounds" attribute pointing to time_bounds, so they aren't really illegal, but they are unnecessary and therefore might be confusing.

Recommend delighting time_bounds from the example.