Merge branch 'main' of github.com:cf-convention/cf-conventions into u…

…grid-2

appd.adoc

@@ -384,7 +384,7 @@ The `nsigma` parameter is deprecated and optional in `formula_terms`; if supplie
 
 The `standard_name` for the vertical coordinate variable is `ocean_sigma_z_coordinate`.
 This variable should contain `sigma(k)*depth_c` for the layers where `sigma` is defined and `zlev(k)` for the other layers, with units of length.
-The layers must be arranged so that the vertical coordinate variable contains a monotonic set of indicative values for the heights of the levels relative to the datum, either increasing or decreasing, and the direction must be indicated by the `positive` attribute, in the usual way for a vertical coordinate variable.
+The layers must be arranged so that the vertical coordinate variable contains a strictly monotonic set of indicative values for the heights of the levels relative to the datum, either increasing or decreasing, and the direction must be indicated by the `positive` attribute, in the usual way for a vertical coordinate variable.
 
 ===  Ocean double sigma coordinate
 

apph.adoc

@@ -76,7 +76,7 @@ The global attribute **`featureType={rdquo}timeSeries{rdquo}`** (case-insensitiv
 ==== Orthogonal multidimensional array representation of time series
 
 If the time series instances have the same number of elements and the time values are identical for all instances, you may use the orthogonal multidimensional array representation.
-This has either a one-dimensional coordinate variable, time(time), provided the time values are ordered monotonically, or a one-dimensional auxiliary coordinate variable, time(o), where o is the element dimension.
+This has either a one-dimensional coordinate variable, time(time), provided the time values are in strict monotonically increasing order, or a one-dimensional auxiliary coordinate variable, time(o), where o is the element dimension.
 In the former case, listing the time variable in the **`coordinates`** attributes of the data variables is optional.
 
 [[example-h.2]]
@@ -474,7 +474,7 @@ The global attribute **`featureType={rdquo}profile{rdquo}`** (case-insensitive)
 ==== Orthogonal multidimensional array representation of profiles
 
 If the profile instances have the same number of elements and the vertical coordinate values are identical for all instances, you may use the orthogonal multidimensional array representation.
-This has either a one-dimensional coordinate variable, z(z), provided the vertical coordinate values are ordered monotonically, or a one-dimensional auxiliary coordinate variable, alt(o), where o is the element dimension.
+This has either a one-dimensional coordinate variable, z(z), provided the vertical coordinate values are in strict monotonic order, or a one-dimensional auxiliary coordinate variable, alt(o), where o is the element dimension.
 In the former case, listing the vertical coordinate variable in the **coordinates** attributes of the data variables is optional.
 
 [[example-h.8, "Atmospheric sounding profiles for a common set of vertical coordinates stored in the orthogonal multidimensional array representation."]]
@@ -587,9 +587,8 @@ This is a special case of the orthogonal multidimensional array representation (
           pressure:coordinates = "time lon lat z" ;
 
       float temperature(z) ;
-          temperature:standard_name = "surface_temperature" ;
-          temperature:long_name = "skin temperature" ;
-          temperature:units = "Celsius" ;
+          temperature:standard_name = "air_temperature" ;
+          temperature:units = "degree_celsius" ;
           temperature:coordinates = "time lon lat z" ;
 
       float humidity(z) ;
@@ -653,9 +652,8 @@ The canonical use case for this is when rewriting raw data, and you expect that
           pressure:coordinates = "time lon lat z" ;
 
       float temperature(obs) ;
-          temperature:standard_name = "surface_temperature" ;
-          temperature:long_name = "skin temperature" ;
-          temperature:units = "Celsius" ;
+          temperature:standard_name = "air_temperature" ;
+          temperature:units = "degree_celsius" ;
           temperature:coordinates = "time lon lat z" ;
 
       float humidity(obs) ;
@@ -695,7 +693,7 @@ If the sample dimension is the unlimited dimension, this allows data to be appen
 
    variables:
       int profile(profile) ;
-          profile:cf_name = "profile_id";
+          profile:cf_role = "profile_id";
       double time(profile);
           time:standard_name = "time";
           time:long_name = "time" ;
@@ -727,9 +725,8 @@ If the sample dimension is the unlimited dimension, this allows data to be appen
           pressure:coordinates = "time lon lat z" ;
 
       float temperature(obs) ;
-          temperature:standard_name = "surface_temperature" ;
-          temperature:long_name = "skin temperature" ;
-          temperature:units = "Celsius" ;
+          temperature:standard_name = "air_temperature" ;
+          temperature:units = "degree_celsius" ;
           temperature:coordinates = "time lon lat z" ;
 
       float humidity(obs) ;
@@ -1112,7 +1109,7 @@ The pressure(i,p,o), temperature(i,p,o), and humidity(i,p,o) data for element o
 Any of the three dimensions could be the netCDF unlimited dimension, if it might be useful to be able enlarge it.
 
 If all of the profiles at any given station have the same set of vertical coordinates values, the vertical auxiliary coordinate variable could be dimensioned alt(station, z).
-If all the profiles have the same set of vertical coordinates, the vertical auxiliary coordinate variable could be one-dimensional alt(z), or replaced by a one-dimensional coordinate variable z(z), provided the values are ordered monotonically.
+If all the profiles have the same set of vertical coordinates, the vertical auxiliary coordinate variable could be one-dimensional alt(z), or replaced by a one-dimensional coordinate variable z(z), provided the values are in strict monotonic order.
 In the latter case, listing the vertical coordinate variable in the coordinates attribute is optional.
 
 If the profiles are taken at all stations at the same set of times, the time auxiliary coordinate variable could be one-dimensional time(profile), or replaced by a one-dimensional coordinate variable time(time), where the size of the time dimension is now equal to the number of profiles at each station.
@@ -1222,7 +1219,7 @@ If there is only one station in the data variable, there is no need for the stat
     :featureType = "timeSeriesProfile";
 ----
 The pressure(p,o), temperature(p,o), and humidity(p,o) data for element o of profile p are associated with the coordinate values time(p), alt(p,o), lat, and lon.
-If all the profiles have the same set of vertical coordinates, the vertical auxiliary coordinate variable could be one-dimensional alt(z), or replaced by a one-dimensional coordinate variable z(z), provided the values are ordered monotonically.
+If all the profiles have the same set of vertical coordinates, the vertical auxiliary coordinate variable could be one-dimensional alt(z), or replaced by a one-dimensional coordinate variable z(z), provided the values are in strict monotonic order.
 In the latter case, listing the vertical coordinate variable in the coordinates attribute is optional.
 ====
 
@@ -1395,7 +1392,7 @@ The pressure(i,p,o), temperature(i,p,o), and humidity(i,p,o) data for element o
 Any of the three dimensions could be the netCDF unlimited dimension, if it might be useful to be able enlarge it.
 
 If all of the profiles along any given trajectory have the same set of vertical coordinates values, the vertical auxiliary coordinate variable could be dimensioned alt(trajectory, z).
-If all the profiles have the same set of vertical coordinates, the vertical auxiliary coordinate variable could be one-dimensional alt(z), or replaced by a one-dimensional coordinate variable z(z), provided the values are ordered monotonically.
+If all the profiles have the same set of vertical coordinates, the vertical auxiliary coordinate variable could be one-dimensional alt(z), or replaced by a one-dimensional coordinate variable z(z), provided the values are in strict monotonic order.
 In the latter case, listing the vertical coordinate variable in the coordinates attribute is optional.
 
 If the profiles are taken along all the trajectories at the same set of times, the time auxiliary coordinate variable could be one-dimensional time(profile), or replaced by a one-dimensional coordinate variable time(time), where the size of the time dimension is now equal to the number of profiles along each trajectory.
@@ -1466,7 +1463,7 @@ If there is only one trajectory in the data variable, there is no need for the t
     :featureType = "trajectoryProfile";
 ----
 The pressure(p,o), temperature(p,o), and humidity(p,o) data for element o of profile p are associated with the coordinate values time(p), alt(p,o), lat(p), and lon(p).
-If all the profiles have the same set of vertical coordinates, the vertical auxiliary coordinate variable could be one-dimensional alt(z), or replaced by a one-dimensional coordinate variable z(z), provided the values are ordered monotonically.
+If all the profiles have the same set of vertical coordinates, the vertical auxiliary coordinate variable could be one-dimensional alt(z), or replaced by a one-dimensional coordinate variable z(z), provided the values are in strict monotonic order.
 In the latter case, listing the vertical coordinate variable in the coordinates attribute is optional.
 ====
 

ch01.adoc

@@ -84,8 +84,8 @@ cell:: A region in one or more dimensions whose boundary can be described by a s
 The term __interval__ is sometimes used for one-dimensional cells.
 
 coordinate variable:: We use this term precisely as it is defined in the
-link:$$http://www.unidata.ucar.edu/software/netcdf/docs/netcdf_data_set_components.html#coordinate_variables$$[NUG section on coordinate variables].
-It is a one-dimensional variable with the same name as its dimension [e.g., **`time(time)`**], and it is defined as a numeric data type with values that are ordered monotonically.
+link:$$https://docs.unidata.ucar.edu/nug/current/best_practices.html#bp_Coordinate-Systems$$[NUG section on coordinate variables].
+It is a one-dimensional variable with the same name as its dimension [e.g., **`time(time)`**], and it is defined as a numeric data type with values in strict monotonic order (all values are different, and they are arranged in either consistently increasing or consistently decreasing order).
 Missing values are not allowed in coordinate variables.
 
 grid mapping variable:: A variable used as a container for attributes that define a specific grid mapping.

ch02.adoc

@@ -16,7 +16,7 @@ NetCDF files should have the file name extension "**`.nc`**".
 === Data Types
 
 // TODO: Check, should this be a bullet list?
-Data variables must be one of the following data types: **`string`**, **`char`**, **`byte`**, **`unsigned byte`**, **`short`**, **`unsigned short`**, **`int`**, **`unsigned int`**, **`int64`**, **`unsigned int64`**, **`float`** or **`real`**, and **`double`** (which are all the [netCDF external data types](https://www.unidata.ucar.edu/software/netcdf/docs/data_type.html#external_types) supported by netCDF-4).
+Data variables must be one of the following data types: **`string`**, **`char`**, **`byte`**, **`unsigned byte`**, **`short`**, **`unsigned short`**, **`int`**, **`unsigned int`**, **`int64`**, **`unsigned int64`**, **`float`** or **`real`**, and **`double`** (which are all the [netCDF external data types](https://docs.unidata.ucar.edu/nug/current/md_types.html) supported by netCDF-4).
 The **`string`** type is only available in files using the netCDF version 4 (netCDF-4) format.
 The **`char`** and **`string`** types are not intended for numeric data.
 One byte numeric data should be stored using the **`byte`** or **`unsigned byte`** data types.

ch09.adoc

@@ -32,16 +32,16 @@ Details and examples of storage of each of these feature types are provided in A
 | **point** 2+| a single data point (having no implied coordinate relationship to other points)
 |||       data(i) | x(i) y(i)  t(i) | <<point-data>>
 
-| **timeSeries** 2+| a series of data points at the same spatial location with monotonically increasing times
+| **timeSeries** 2+| a series of data points at the same spatial location with time values in strict monotonically increasing order
 |||      data(i,o) | x(i) y(i) t(i,o) | <<time-series-data>>
 
-| **trajectory** 2+| a series of data points along a path through space with monotonically increasing times
+| **trajectory** 2+| a series of data points along a path through space with time values in strict monotonically increasing order
 |||        data(i,o)    | x(i,o) y(i,o) t(i,o) | <<trajectory-data>>
 
 | **profile** 2+| an ordered set of data points along a vertical line at a fixed horizontal position and fixed time
 |||        data(i,o)    | x(i) y(i) z(i,o) t(i) | <<profile-data>>
 
-| **timeSeriesProfile** 2+| a series of profile features at the same horizontal position with monotonically increasing times
+| **timeSeriesProfile** 2+| a series of profile features at the same horizontal position with time values in strict monotonically increasing order
 |||        data(i,p,o)      | x(i) y(i) z(i,p,o) t(i,p) | <<time-series-profiles>>
 
 | **trajectoryProfile** 2+| a series of profile features located at points ordered along a trajectory

history.adoc

@@ -7,6 +7,10 @@
 
 === Working version (most recent first)
 
+* {issues}458[Issue #458]: Fix broken link to Unidata documentation.
+* {issues}423[Issue #423]: Always use "strictly monotonic" when describing coordinate variables
+* {issues}420[Issue #420]: Add List of Figures
+* {issues}210[Issue #210]: Correct errors in examples H9-H11
 * {issues}374[Issue #374]: Clarify rules for packing and unpacking in Section 8.1
 * {issues}449[Issue #449]: Typo in end-date in Example 7.12
 * {issues}266[Issue #266]: Updates to some links in the bibliography

toc-extra.adoc

@@ -13,6 +13,25 @@ I.1. <<table-cf-concepts>>
 I.2. <<table-cf-constructs>>
 K.2. <<table-mesh-topology-attributes>>
 
+**List of Figures**
+
+[%hardbreaks]
+7.1. <<img-bnd_1d_coords, figure 1>>
+7.2. <<img-bnd_2d_coords, figure 2>>
+8.1. <<interpolation_subarea_generation>>
+8.2. <<ci_dimensions_overview>>
+8.3. <<ci_interpolation_parameters>>
+8.4. <<figure_interpolation_of_cell_boundaries>>
+I.1. <<figure-cf-concepts>>
+I.2. <<figure-field>>
+I.3. <<figure-dim-aux>>
+I.4. <<figure-coordinate-reference>>
+J.1. <<interpolation_subareas_1d>>
+J.2. <<interpolation_subarea_2d>>
+J.3. <<quadratic1>>
+J.4. <<quadratic2>>
+J.5. <<quadratic3>>
+
 **List of Examples**
 
 [%hardbreaks]