From 44fcdb128860d963a5ed1ccb0cf8fca1f345d98e Mon Sep 17 00:00:00 2001 From: Dave Allured Date: Wed, 2 Dec 2020 12:26:32 -0700 Subject: [PATCH] Attributes that are not CF significant Attributes that are not CF significant are not required to match --- ch07.adoc | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/ch07.adoc b/ch07.adoc index 0970ab95..15ad89d2 100644 --- a/ch07.adoc +++ b/ch07.adoc @@ -11,7 +11,9 @@ When gridded data does not represent the point values of a field but instead rep To represent cells we add the attribute **`bounds`** to the appropriate coordinate variable(s). The value of **`bounds`** is the name of the variable that contains the vertices of the cell boundaries. We refer to this type of variable as a "boundary variable." __A boundary variable will have one more dimension than its associated coordinate or auxiliary coordinate variable.__ The additional dimension should be the most rapidly varying one, and its size is the maximum number of cell vertices. -Since a boundary variable is considered to be part of a coordinate variable's metadata, it is not necessary to provide it with attributes such as **`long_name`** and **`units`**. Functional attributes which determine the coordinate type (**`units`**, **`standard_name`**, **`axis`** and **`positive`**), or those which affect the interpretation of the array values (**`units`**, **`calendar`**, **`leap_month`**, **`leap_year`** and **`month_lengths`**), should be inherited from the associated parent coordinate variable, rather than being attached to the boundary variable itself. Duplication of such functional attributes on the boundary variable is permissible but not recommended. When such duplicates are included, their string or numeric values must be exactly the same as the parent variable attributes. Their data types do not need to be an exact match. +Since a boundary variable is considered to be part of a coordinate variable's metadata, it is not necessary to provide it with redundant attributes such as **`long_name`** and **`units`**. Functional attributes which determine the coordinate type (**`units`**, **`standard_name`**, **`axis`** and **`positive`**), or those which affect the interpretation of the array values (**`units`**, **`calendar`**, **`leap_month`**, **`leap_year`** and **`month_lengths`**), should be inherited from the associated parent coordinate variable, rather than being attached to the boundary variable itself. Duplication of such functional attributes on the boundary variable is permissible but not recommended. When such duplicates are included, their string or numeric values must be exactly the same as the parent variable attributes. Their data types do not need to be an exact match. + +Attributes which are **not** significant to CF interpretation, **`long_name`** and so forth, are also generally unnecessary on the boundary variable. Such attributes are not required to match between coordinate and boundary variables. However, when present, it is recommended that they not be contradictory or confusing to the reader. If a parametric coordinate variable with a **`formula_terms`** attribute (section 4.3.2) also has a **`bounds`** attribute, its boundary variable must have a **`formula_terms`** attribute too. In this case the same terms would appear in both (as specified in Appendix D), since the transformation from the parametric coordinate values to physical space is realized through the same formula. For any term that depends on the vertical dimension, however, the variable names appearing in the formula terms would differ from those found in the **`formula_terms`** attribute of the coordinate variable itself because the boundary variables for formula terms are two-dimensional while the formula terms themselves are one-dimensional.