Opened 3 years ago

Last modified 3 years ago

#151 new enhancement

Clarification of use of standard region names in "region" variables. — at Version 2

Reported by: martin.juckes Owned by: cf-conventions@…
Priority: medium Milestone:
Component: cf-conventions Version:
Keywords: Cc:

Description (last modified by martin.juckes)

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 descriptions for CF standard names

region

A variable with the standard_name of region contains strings which indicate a geographical region or integers which can be translated to strings using flag_values and flag_meanings attributes. These strings are standardised. Values must be taken from the CF standard region list.

area_type

A variable with the standard_name of area_type contains strings which indicate the nature of the surface e.g. land, sea, sea_ice, or integers which can be translated to strings using flag_values and flag_meanings attributes. These strings are standardised. Values must be taken from the area_type table.

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 of region, area_type or any other standard name which requires string-valued values from a defined list may alternatively be of integer type and use flag_values and flag_meanings attributes to record the translation between the integers and the string values, for instance:

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

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).

Variables with standard name area_type must be one of:

  • type character, with values taken from the area type table;
  • type integer, with flag_values and flag_meanings attributes. The flag_meanings attributes must be a space separatd list of values from the area type table (analogous to example 6.2).

Change History (2)

comment:1 Changed 3 years ago by jonathan

Dear Martin

Thanks for making this proposal. As you know I agree with the principle. I'd like to generalise it to other similar cases, so I would suggest modifying your text

A variable with standard name of 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:

to

A variable with standard name of region, area_type or any other standard name which requires string-valued values from a defined list may alternatively be of integer type and use flag_values and flag_meanings attributes to record the translation between the integers and the string values, for instance:

and then give your example as it is. (I think "translate" is more explicit than "relationship" but you may disagree!) This also requires a modified definition for area_type:

A variable with the standard name of area_type contains strings which indicate the nature of the surface e.g. land, sea, sea_ice, or integers which can be translated to strings using flag_values and flag_meanings attributes. These strings are standardised. Values must be taken from the area_type table.

I'm not convinced about modifying Appendix B. I feel that it should be adequate to note the constraints for specific standard names in the table itself. We could also make a note about the existence of constraints on the standard name page. If we were to make a separate list of them, it should be comprehensive. For instance, there are a number which expect or require particular coordinates variables to exist.

Best wishes

Jonathan

comment:2 Changed 3 years ago by martin.juckes

  • Description modified (diff)
Note: See TracTickets for help on using tickets.