Formatting of local links in text; Lists of Figures, Tables and Examples

appd.adoc

@@ -356,13 +356,12 @@ formula_terms = "sigma: var1 depth: var2 z1: var3 z2: var4 a: var5 href: var6
 The `standard_name` for `depth` and the `computed_standard_name` must be one of the consistent sets shown in <<table-computed-standard-names, Table D.1>>.
 No `standard_name` has been defined for `z1`, `z2`, `a`, `href` or `k_c`.
 
-// This table has an unusually long title, and AsciiDoctor is unable to wrap it.
-// 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:
+// (Leaving this comment here in case it's useful in the future!)
+// This table used to have an unusually long title, and AsciiDoctor was unable to wrap it.
+// But AsciiDoctor will wrap an image title, so the title was assigned to a 1-pixel transparent image,
+// and the table put immediately thereafter, with its own title
 [[table-computed-standard-names]]
-.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::images/NFFFFFF-1.0.png[caption=""]
-
+.Consistent sets of values for the standard_names of formula terms and the computed_standard_name
 [options="header",cols="1,3,2,3",caption="Table D.1. "]
 |===============
 

appf.adoc

@@ -173,7 +173,7 @@ link:$$https://proj.org/operations/projections/cea.html$$[https://proj.org/opera
 and
 link:$$http://geotiff.maptools.org/proj_list/cylindrical_equal_area.html$$[http://geotiff.maptools.org/proj_list/cylindrical_equal_area.html]
 ("Lambert Cylindrical Equal Area" or EPSG 9834 or EPSG 9835).
-Detailed formulas can be found in <<bibliography.adoc#Snyder>> pages 76-85.
+Detailed formulas can be found in <<Snyder>> pages 76-85.
 
 === Latitude-Longitude
 
@@ -280,7 +280,7 @@ and
 link:$$http://geotiff.maptools.org/proj_list/polar_stereographic.html$$[http://geotiff.maptools.org/proj_list/polar_stereographic.html].
 
 The standard_parallel variant corresponds to EPSG Polar Stereographic (Variant B) (EPSG dataset coordinate operation method code 9829), while the scale_factor_at_projection_origin variant corresponds to EPSG Polar Stereographic (Variant A) (EPSG dataset coordinate operation method code 9810).
-As PROJ requires the standard parallel, [Snyder] formula 21-7 can be used to compute it from the scale factor if needed.
+As PROJ requires the standard parallel, <<Snyder>> formula 21-7 can be used to compute it from the scale factor if needed.
 
 === Rotated pole
 

appi.adoc

@@ -40,7 +40,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]]
-.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
 [options="header",cols="2",caption="Table I.1. "]
 |===============
 |{set:cellbgcolor!}
@@ -107,7 +107,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]]
-.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
 [options="header",cols="2",caption="Table I.2. "]
 |===============
 |{set:cellbgcolor!}

appj.adoc

@@ -87,7 +87,11 @@ In the two-dimensional case, `a = tp(tpi2, tpi1)`, `b = tp(tpi2, tpi1+1)`, `c =
 [[common-conversions-and-formulas, Section J.2, "Common Conversions and Formulas"]]
 ==== Common Conversions and Formulas
 
-[cols="2, 8, 8"]
+<<subsampling-formulae, Table J.1>> describes conversions and formulas that are used in the descriptions of the interpolation techniques.
+
+[[table-subsampling-formulas]]
+.Conversions and formulas used in the definitions of subsampling interpolation methods
+[cols="2, 8, 8", options="header",caption="Table J.1. "]
 |===============
 | |Description | Formula
 

ch01.adoc

@@ -54,7 +54,7 @@ Therefore CF-netCDF does not use codes, but instead relies on controlled vocabul
 [[terminology, Section 1.3, "Terminology"]]
 === Terminology
 
-The terms in this document that refer to components of a netCDF file are defined in the NetCDF User's Guide (NUG) <<NUG>> NUG.
+The terms in this document that refer to components of a netCDF file are defined in the NetCDF User's Guide (NUG) <<NUG>>.
 Some of those definitions are repeated below for convenience.
 
 ancestor group:: A group from which the referring group is descended via direct parent-child relationships

ch03.adoc

@@ -139,7 +139,7 @@ Use of these attributes for data packing, which is their most important applicat
 [[long-name, Section 3.2, "Long Name"]]
 === Long Name
 
-The **`long_name`** attribute is defined by the NUG to contain a long descriptive name which may, for example, be used for labeling plots.
+The **`long_name`** attribute is defined by the NUG <<NUG>> to contain a long descriptive name which may, for example, be used for labeling plots.
 For backwards compatibility with COARDS this attribute is optional.
 But it is highly recommended that either this or the **`standard_name`** attribute defined in the next section be provided for all data variables and variables containing coordinate data, in order to make the file self-describing.
 If a variable has no **`long_name`** attribute then an application may use, as a default, the **`standard_name`** if it exists, or the variable name itself.

ch04.adoc

@@ -122,7 +122,7 @@ Recommendations:  The **`positive`** attribute should be consistent with the sig
 ==== Dimensional Vertical Coordinate
 
 
-Variables representing dimensional vertical coordinates for or height must always explicitly include the  **`units`** attribute.
+Variables representing dimensional vertical coordinates for depth or height must always explicitly include the  **`units`** attribute.
 The acceptable units for a vertical (depth or height) coordinate variable must a UDUNITS <<UDUNITS>> representation of one of the following:
 
 * units of pressure.

ch05.adoc

@@ -20,7 +20,7 @@ We recommend that the name of a multidimensional coordinate variable should not
 This practice also avoids potential bugs in applications that determine coordinate variables by only checking for a name match between a dimension and a variable and not checking that the variable is one dimensional.
 
 If the longitude, latitude, vertical or time coordinate is multi-valued, varies in only one dimension, and varies independently of other spatiotemporal coordinates, it is not permitted to store it as an auxiliary coordinate variable.
-This is both to enhance conformance to COARDS and to facilitate the use of generic applications that recognize the NUG convention for coordinate variables.
+This is both to enhance conformance to COARDS and to facilitate the use of generic applications that recognize the NUG <<NUG>> convention for coordinate variables.
 An application that is trying to find the latitude coordinate of a variable should always look first to see if any of the variable's dimensions correspond to a latitude coordinate variable.
 If the latitude coordinate is not found this way, then the auxiliary coordinate variables listed by the `coordinates` attribute should be checked.
 Note that it is permissible, but optional, to list coordinate variables as well as auxiliary coordinate variables in the `coordinates` attribute.

ch07.adoc

@@ -807,7 +807,9 @@ This interior ring variable must contain the value 0 to indicate an exterior rin
 The single dimension of the interior ring variable must be the same dimension as that of the part node count variable.
 The geometry types included in this convention are listed in Table 7.1.
 
-[cols="4"]
+[[table-geometry-types]]
+.Dimensionality, description, and additional required attributes for geometry_types.
+[cols="4", options="header",caption="Table 7.1. "]
 |===============
 | geometry_type | Dimensionality | Description of Geometry Instance | Additional required attributes on geometry container variable
 
@@ -818,8 +820,6 @@ The geometry types included in this convention are listed in Table 7.1.
 | **polygon** | 2 | A collection of one or more polygons, where a polygon is a planar surface comprised of an exterior ring and zero or more interior rings (i.e., holes), where a ring is a closed line (i.e., the last point in the line is assumed to be connected to the first point) | node_count, part_node_count (if holes or multipart geometries are present), interior_ring (if holes are present)
 |===============
 
-**Table 7.1.** Dimensionality, description, and additional required attributes for geometry_types.
-
 [[complete-multipolygon-example]]
 [caption="Example 7.16. "]
 .Polygons with holes

ch08.adoc

@@ -17,7 +17,7 @@ The disadvantage is that generic utilities that don't recognize the CF conventio
 === Packed Data
 
 At the current time the netCDF interface does not provide for packing data.
-However a simple packing may be achieved through the use of the optional NUG defined attributes **`scale_factor`** and **`add_offset`**.
+However a simple packing may be achieved through the use of the optional NUG <<NUG>> defined attributes **`scale_factor`** and **`add_offset`**.
 After the data values of a variable have been read, they are to be multiplied by the **`scale_factor`**, and have **`add_offset`** added to them.
 If both attributes are present, the data are scaled before the offset is added.
 When scaled data are written, the application should first subtract the offset and then divide by the scale factor.
@@ -588,8 +588,8 @@ The full set of bounds tie points is formed by appending, for each continuous ar
 
 **Bounds Tie Point Attribute and Bounds Tie Point Variable** +
 A **`bounds_tie_points`** attribute must be defined for each tie point coordinate variable corresponding to reconstituted coordinates with cell boundaries.
-It is a single word of the form __“bounds_tie_point_variable”__ that identifies a bounds tie point variable, containing a bounds tie point coordinate value for each tie point stored in its tie point coordinate variable, and therefore the bounds tie point variable has the same set of dimensions as its tie point coordinate variable.
-An example of the usage of the **`bounds_tie_points`** is shown in <<example-interpolation-of-cell-boundaries>>.
+Its string value identifies a __bounds tie point variable__ which contains a bounds tie point coordinate value for each tie point stored in its tie point coordinate variable, and therefore the bounds tie point variable has the same set of dimensions as its tie point coordinate variable.
+An example of the usage of the **`bounds_tie_points`** is shown in <<example-interpolation-of-cell-boundaries, Example 8.7>>.
 Since a bounds tie point variable is considered to be part of a tie point coordinate variable’s metadata, it is not necessary to provide it with attributes such as long_name and units, following the same rules as for the bounds of an uncompressed coordinate variable, see <<cell-boundaries>>.
 
 **Uncompressing coordinate bounds** +
@@ -604,9 +604,9 @@ For one-dimensional coordinate bounds, in the second step of the process, for ea
 **Uncompression of two-dimensional coordinate bounds** +
 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, Interpolation of 2D Cell Boundaries corresponding to Figure 8.4]]
+[[example-interpolation-of-cell-boundaries]]
 [caption="Example 8.7. "]
-.Interpolation of 2D Cell Boundaries corresponding to <<figure_interpolation_of_cell_boundaries>>
+.Interpolation of the 2D cell boundaries corresponding to Figure 8.4
 ====
 ----
 dimensions:
@@ -668,8 +668,8 @@ The data creator shall specify the floating-point arithmetic precision used duri
 [cols="3,10"]
 |===============
 | ** Value ** | ** Description**
-| "32" | 32-bit floating-point arithmetic, comparable to the binary32 standard in [<<IEEE_754>>]
-| "64" | 64-bit floating-point arithmetic, comparable to the binary64 standard in [<<IEEE_754>>]
+| "32" | 32-bit floating-point arithmetic, comparable to the IEEE binary32 standard <<IEEE_754>>
+| "64" | 64-bit floating-point arithmetic, comparable to the IEEE binary64 standard <<IEEE_754>>
 |===============
 
 Using the given computational precision in the interpolation computations is a necessary, but not sufficient, condition for the data user to be able to reconstitute the coordinates to an accuracy comparable to that intended by the data creator.