Custom Query (124 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (91 - 93 of 124)

Ticket Resolution Summary Owner Reporter
#49 fixed Clarification of flag_meanings attribute jonathan martin.juckes
Description

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.

#138 fixed Clarification of false_easting / false_northing davidhassell heiko.klein
Description

The explanation of false_easting/northing has left us often puzzled weather false_easting should be added to the existing x-axis values, or subtracted. To clarify this, I suggest the following modification to Table F.1:

false_easting

The value applied to all abscissa values in the rectangular coordinates for a map projection. This value frequently is assigned to eliminate negative numbers. Expressed in the unit of the coordinate variable identified by the standard name projection_x_coordinate. The formula to convert from a projection-axis value without false_easting (x0) to a projection-axis value with false_easting is (xf) is:
x0 = xf - false_easting

false_northing

The value applied to all ordinate values in the rectangular coordinates for a map projection. This value frequently is assigned to eliminate negative numbers. Expressed in the unit of the coordinate variable identified by the standard name projection_y_coordinate. The formula to convert from a projection-axis value without false_northing (y0) to a projection-axis value with false_northing is (yf) is then:
y0 = yf - false_northing

#52 fixed Clarification of _FillValue attribute cf-conventions@… ros
Description

Section 2.5.1 of the convention defines the standard for the _FillValue attribute stating that it is "a scalar attribute and must have the same type as its variable." There are no specific exclusions, but I think that allowing the value NaN isn't a good idea.

The NetCDF standard doesn't prohibit the use of NaN as a _FillValue, but I did find several recommendations not to use NaN. The problem with allowing NaN is that any calculation or comparisons with NaN will return false.

I suggest a modification to the convention to recommend against the use of NaN as a _FillValue value.

Thoughts?

Note: See TracQuery for help on using queries.