Merge pull request #417 from neumannd/rename_some_example_for_consist…

…ency

Rename some examples for consistency

appd.adoc

@@ -431,7 +431,7 @@ No `standard_name` has been defined for `z1`, `z2`, `a`, `href` or `k_c`.
 // But AsciiDoctor will wrap an image title, so assign the title to a 1-pixel transparent image,
 // and put the table immediately thereafter, with its own title:
 [[table-computed-standard-names]]
-.Table D.1.  Consistent sets of values for the standard_names of formula terms and the computed_standard_name needed in defining the ocean sigma coordinate, the ocean s-coordinate,  the ocean_sigma over z coordinate, and the ocean double sigma coordinate.
+.Consistent sets of values for the standard_names of formula terms and the computed_standard_name needed in defining the ocean sigma coordinate, the ocean s-coordinate,  the ocean_sigma over z coordinate, and the ocean double sigma coordinate.
 image::NFFFFFF-1.0.png[caption=""]
 
 [options="header",cols="1,3,2,3",caption="Table D.1."]

apph.adoc

@@ -12,7 +12,7 @@ Because each feature contains only a single data element, there is no need for a
 The representation of point features is a special, degenerate case of the standard four representations.
 The **`coordinates`** attribute is used on the data variables to unambiguously identify the relevant space and time auxiliary coordinate variables.
 
-[[example-h.1, Example H.1, "Point data"]]
+[[example-h.1, "Point data"]]
 [caption="Example H.1. "]
 .Point data.
 ====
@@ -477,7 +477,7 @@ If the profile instances have the same number of elements and the vertical coord
 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.
 In the former case, listing the vertical coordinate variable in the **coordinates** attributes of the data variables is optional.
 
-[[example-h.8, Example H.8, "Atmospheric sounding profiles for a common set of vertical coordinates stored in the orthogonal multidimensional array representation."]]
+[[example-h.8, "Atmospheric sounding profiles for a common set of vertical coordinates stored in the orthogonal multidimensional array representation."]]
 [caption="Example H.8. "]
 .Atmospheric sounding profiles for a common set of vertical coordinates stored in the orthogonal multidimensional array representation.
 ====

appi.adoc

@@ -41,7 +41,7 @@ The CF-netCDF elements are listed in <<table-cf-concepts, Table I.1>> and shown
 The CF data model has been derived from these CF-netCDF elements and relationships with the aims of removing aspects specific to the netCDF encoding, and reducing the number of elements, whilst retaining the ability to describe the CF conventions fully, in order to meet the design criteria.
 
 [[table-cf-concepts]]
-.Table I.1. The elements of the CF-netCDF conventions. The relationships to netCDF elements are shown in <<figure-cf-concepts>>.
+.The elements of the CF-netCDF conventions. The relationships to netCDF elements are shown in <<figure-cf-concepts>>.
 [options="header",cols="2",caption=""]
 |===============
 |{set:cellbgcolor!}
@@ -103,7 +103,7 @@ The elements of the CF data model (<<figure-field>>, <<figure-dim-aux>> and <<fi
 The constructs, listed in <<table-cf-constructs, Table I.2>>, are related to CF-netCDF elements (<<figure-cf-concepts>>), which in turn relate to the components of netCDF file.
 
 [[table-cf-constructs]]
-.Table I.2. The constructs of the CF data model. The relationships between the constructs and CF-netCDF elements are shown in in <<figure-field>>, <<figure-dim-aux>> and <<figure-coordinate-reference>>.
+.The constructs of the CF data model. The relationships between the constructs and CF-netCDF elements are shown in in <<figure-field>>, <<figure-dim-aux>> and <<figure-coordinate-reference>>.
 [options="header",cols="2",caption=""]
 |===============
 |{set:cellbgcolor!}
@@ -310,7 +310,7 @@ In the case of a named term being a type of coordinate variable, that variable w
 
 [[cdl-domain-anc-coordinate]]
 [caption=""]
-.Example I.1 A single CF-netCDF variable corresponding to two data model constructs.
+.A single CF-netCDF variable corresponding to two data model constructs.
 ====
 ----
 float eta(eta) ;

ch05.adoc

@@ -299,7 +299,7 @@ This should prevent a COARDS compliant application from mistaking the variables
 The entries for these names in the standard name table indicate the appropriate sign conventions for the units of **`degrees`**.
 
 
-[[lambert-conformal-projection,Example 5.7, "Lambert conformal projection"]]
+[[lambert-conformal-projection, "Lambert conformal projection"]]
 [caption="Example 5.7. "]
 .Lambert conformal projection
 ====
@@ -697,7 +697,7 @@ For this reason we strongly recommend against using a name for a scalar coordina
 If a data variable has two or more scalar coordinate variables, they are regarded as though they were all independent coordinate variables with dimensions of size one.
 If two or more single-valued coordinates are not independent, but have related values (this might be the case, for instance, for time and forecast period, or vertical coordinate and model level number, <<alternative-coordinates>>), they should be stored as coordinate or auxiliary coordinate variables of the same size one dimension, not as scalar coordinate variables.
 
-[[multiple-forecasts-from-single-analysis,Example 5.13, "Multiple forecasts from a single analysis"]]
+[[multiple-forecasts-from-single-analysis, "Multiple forecasts from a single analysis"]]
 [caption="Example 5.14. "]
 .Multiple forecasts from a single analysis
 ====

ch08.adoc

@@ -602,8 +602,8 @@ For one-dimensional coordinate bounds, in the second step of the process, for ea
 For two-dimensional coordinate bounds, in the second step of the process, for each index pair `(j, i)` of the interpolated dimension, the four bounds of the boundary variable is set to the value of the interpolated bounds point grid at index pairs `B0`, `B1`, `B2` and `B3`, respectively, where the index pairs are defined above under <<compressing_two_dimensional>>.
 
 
-[[example_interpolation_of_cell_boundaries, Example 8.7]]
-[caption="Example 8.7 "]
+[[example-interpolation-of-cell-boundaries]]
+[caption="Example 8.7. "]
 .Interpolation of 2D Cell Boundaries corresponding to <<figure_interpolation_of_cell_boundaries>>
 ====
 ----

history.adoc

@@ -13,6 +13,7 @@
 * {pull-requests}408[Pull request #408]: Deleted a sentence on "rotated Mercator" under `Oblique Mercator` grid mapping in Appendix F
 * {issues}260[Issue #260]: Clarify use of dimensionless units
 * {issues}410[Issue #410]: Delete "on a spherical Earth" from the definition of the `latitude_longitude` grid mapping in Appendix F 
+* {issues}286[Issue #286]: Some labels of examples contain "Example" so that their label in the list of examples contains "Example" (affects four examples)
 
 === Version 1.10 (31 August 2022)
 

toc-extra.adoc

@@ -64,6 +64,7 @@ I.2. <<table-cf-constructs>>
 8.4. <<example-1d-interpolation-of-2d-domain>>
 8.5. <<example-VIIRS>>
 8.6. <<example-grid-mapping-and-interpolation-with-time-not-interpolated>>
+8.7. <<example-interpolation-of-cell-boundaries>>
 B.1. <<name-table-three-entries-ex>>
 H.1. <<example-h.1>>
 H.2. <<example-h.2>>