Custom Query (125 matches)

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.

The CF standard name region has the current description "A variable with the standard name of region contains strings which indicate geographical regions. These strings must be chosen from the standard region list." This description implies that the variable should be of character type, but it is often more convenient to have an integer variable and make a clear link to the region names using flag_values and flag_meanings. The proposal is to clarify the definition so that either usage is acceptable and include an example of the latter usage in the convention text. It is also proposed that an appendix be added to the CF Convention text to state clearly any constraints on file meta-data which are implied by the CF Standard Name definitions, so that it is possible to test such constraints in the CF checker.

New description for CF standard name "region"

A variable with the standard name of region must have values associated with geographical regions from the CF standard region list, either as a character variable using the region names directly or as an integer variable with values linked to region names through flag_values and flag_meanings attributes.

New usage example in CF Convention text

The following should be placed at the end of 6.1.1, after example 6.2

A variable with standard name 'region' may also be of integer type and use 'flag_values' and 'flag_meanings' attributes to express the relationship between the integers and the region names:

integer basin(basin);
       standard_name: region;
       flag_values: '1 2 3';
       flag_meanings:'atlantic_arctic_ocean indo_pacific_ocean global_ocean';
......
values::
   basin: 1, 2, 3;

New Appendix Section

Change "Appendix B: Standard Name Table Format" to:

Appendix B: Standard Names

B.1: Standard Name Table Format

.....

and

B.2 Constraints for specific standard names

B.2.1: region

Variables with standard name region must be one of:

• type character, with values taken from the CF standard region list;
• type integer, with flag_values and flag_meanings attributes. The flag_meanings attributes must be a space separatd list of values from the CF standard region list (see example 6.2).

Dear all

I have the honour of opening ticket number 100. In this ticket, Steve Hankin and I have a number of changes to propose to the text of section 5, with the intention of clarifying it, not changing what it means. Therefore this is a defect ticket, but please object if you think it is changing the meaning, or making it any less clear!

Cheers

Jonathan

Replace this text in the first paragraph

A variable's spatiotemporal dimensions are used to locate data values in time and space. This is accomplished by associating these dimensions with the relevant set of latitude, longitude, vertical, and time coordinates.

with

A data variable's dimensions are used to locate data values in time and space or as a function of other independent variables. This is accomplished by associating these dimensions with the relevant set of latitude, longitude, vertical, time and any non-spatiotemporal coordinates.

These changes clarify that coordinate systems belong to data variables (rather than any other type of variable in a CF-netCDF file) and recognise the use of non-spatiotemporal dimensions.

Replace this text in the second paragraph

All of a variable's dimensions that are latitude, longitude, vertical, or time dimensions (see Section 1.2, "Terminology") must have corresponding coordinate variables, i.e., one-dimensional variables with the same name as the dimension

with

Any of a variable's dimensions that is an independently varying latitude, longitude, vertical, or time dimension (see Section 1.2, "Terminology") and that has a size greater than one must have a corresponding coordinate variable, i.e., a one-dimensional variable with the same name as the dimension

These changes remove the implication that spatiotemporal scalar coordinates might be prohibited, and allow for discrete axes (section 4.5, used extensively in section 9).

Replace this text in the third paragraph

All of a variable's spatiotemporal dimensions that are not latitude, longitude, vertical, or time dimensions are required to be associated with the relevant latitude, longitude, vertical, or time coordinates via the new coordinates attribute of the variable

with

Any longitude, latitude, vertical or time coordinate which depends on more than one spatiotemporal dimension must be identified by the coordinates attribute of the data variable.

This change is for clarity.

Replace this text in the fifth paragraph

The use of coordinate variables is required whenever they are applicable. That is, auxiliary coordinate variables may not be used as the only way to identify latitude and longitude coordinates that could be identified using coordinate variables.

with

If the longitude, latitude, vertical or time coordinate is multi-valued and varies in only one dimension, it is not permitted to store it as an auxiliary coordinate variable.

This change is for simplicity and clarity. The use of coordinate variables where applicable is already required by the second paragraph.

Append to the fifth paragraph

If the longitude, latitude, vertical or time coordinate is single-valued, it may be stored either as a coordinate variable with a dimension of size one, or as a scalar coordinate variable (Section 5.7).

This change recognises the use of spatiotemporal scalar coordinates.