#151: Clarification of use of standard region names in "region" variables.
-----------------------------+------------------------------
Reporter: martin.juckes | Owner: cf-conventions@…
Type: enhancement | Status: new
Priority: medium | Milestone:
Component: cf-conventions | Version:
Resolution: | Keywords:
-----------------------------+------------------------------
Description changed by martin.juckes:
Old description:
> 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).
New description:
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 flags 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 flags 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 after example 3.3, renumbering examples
3.4 and 3.5 to 3.5 and 3.6 respectively (text checked for cross-references
to "3.4" and "3.5" and none found)''
A variable with standard name of `region`, `area_type` or any other
standard name which requires string-valued values from a defined list may
use flags together with `flag_values` and `flag_meanings` attributes to
record the translation to the string values. The following example
illustrates this using integer flag values:
Example 3.4. Flag variable with controlled values, using `flag_values`
{{{
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, .....
}}}
== Hook in section 3.3 to highlight existence of constraints implied by
standard name ==
''In section 3.3, append to the paragraph about "description", after
"The description is meant to clarify the qualifiers of the fundamental
quantities such as which surface a quantity is defined on or what the flux
sign conventions are. We don"t attempt to provide precise definitions of
fundumental physical quantities (e.g., temperature) which may be found in
the literature." the following:''
The description may define rules on the variable type and attributes (such
as in example 3.4) which must be complied with by any variable carrying
that standard name.
''Note that also that there is a typo in the text cited aboove `don"t`
instead of `don't`''
--
--
Ticket URL: <http://cf-trac.llnl.gov/trac/ticket/151#comment:9>
CF Metadata <http://cf-convention.github.io/>
CF Metadata
