Custom Query (124 matches)


Show under each result:

Results (79 - 81 of 124)

Ticket Resolution Summary Owner Reporter
#51 fixed syntax consistency for dimensionless vertical coordinate definitions cf-conventions@… taylor13

I suggest that for readability and for consistency in the syntax of the definitions of dimensionless vertical coordinates, the following changes be made in the CF documentation.

  1. Where the coordinate definition involves a construction like "for k<=k_c .... for k>k_c ....", follow each "for" phrase with a colon. [This is currently done inconsistently.]
  1. Where the coordinate definition involves a term that is subsequently defined (e.g., the C(k) in the ocean-S coordinate), precede the definition of the term with "where".

These make the definitions easier to read. Note that CF does not mandate storage of the coordinate definitions in the netCDF files, but for CMIP, we store the formulas as a text string attribute attached to the coordinate variable and named "formula".

#50 fixed Upgrade CF Checker to use CDAT-5.x and udunits2 ros ros

Upgrade CF Checker to work with CDAT-5.x and udunits2

#49 fixed Clarification of flag_meanings attribute jonathan martin.juckes

1. Title

Clarification of flag_meanings attribute

2. Moderator

Jonathan Gregory

3. Requirement

Clear definition and greater range of characters in flag_meanings attribute.

4. Initial Statement of Technical Proposal

Section 3.5 of the convention states "The flag_meanings attribute is a string whose value is a blank separated list of descriptive words or phrases, one for each flag value.", and a "word" is currently interpreted by the CF-checker to consist only of alphanumeric characters, ruling out hyphens and brackets which may be useful in this context. The proposal is that a word in this context should be defined to consist of alphanumeric characters plus underscore '_', period '.', plus '+', hyphen '-', or "at" sign '@', to be consistent with the character set allowed for netCDF variable/dim/attr names [there is no particular need for this consistency, except to avoid having multiple definitions of what constitutes a word].

The above sentence from section 3.5 should be modified to read "The flag_meanings attribute is a string whose value is a blank separated list of descriptive words or phrases, one for each flag value. Each word or phrase consisting of characters from the alphanumeric set or from the following four: '-', '.', '+', '@'.",

5. Benefits

More meaningful "flag_meanings" will be possible.

E.g. for a dataset of eco-regions, flag_meanings such as "Alberta-British Columbia foothills forests" could be used.

6. Status Quo

There is ambiguity in the current standard, which I believe should be alleviated.

Note: See TracQuery for help on using queries.