Merge pull request cf-convention#535 from JonathanGregory/issue530

Define "the most rapidly varying dimension"

ch01.adoc

@@ -94,6 +94,8 @@ The word "apex" refers to position of this group at the vertex of the tree of gr
 
 longitude dimension:: A dimension of a netCDF variable that has an associated longitude coordinate variable.
 
+most rapidly varying dimension:: The dimension of a multidimensional variable for which elements are adjacent in storage. When netCDF is represented in CDL, the most rapidly varying dimension is the last one e.g. **`x`** in **`float data(z,y,x)`**. C and Python NumPy use the same order as C, also called "column-major order", but Fortran uses the opposite convention, also called "row-major order", so that when netCDF variables are accessed in Fortran the most rapidly varying dimension is the first one.
+
 multidimensional coordinate variable:: An auxiliary coordinate variable that is multidimensional.
 
 nearest item:: The item (variable or group) that can be reached via the shortest traversal of the file from the referring group following the rules set forth in the <<groups>>.
@@ -190,7 +192,7 @@ But because of the extensions that provide new metadata content, and the relaxat
 The features of these conventions that allow writing netCDF files that are not COARDS conforming are summarized below.
 
 COARDS standardizes the description of grids composed of independent latitude, longitude, vertical, and time axes.
-In addition to standardizing the metadata required to identify each of these axis types COARDS restricts the axis (equivalently dimension) ordering to be longitude, latitude, vertical, and time (with longitude being the most rapidly varying dimension).
+In addition to standardizing the metadata required to identify each of these axis types, COARDS requires (_time_, _vertical_, _latitude_, _longitude_) as the CDL order for the dimensions of a variable, with longitude being the most rapidly varying dimension (the last dimension in CDL order).
 Because of I/O performance considerations it may not be possible for models to output their data in conformance with the COARDS requirement.
 The CF convention places no rigid restrictions on the order of dimensions, however we encourage data producers to make the extra effort to stay within the COARDS standard order.
 The use of non-COARDS axis ordering will render files inaccessible to some applications and limit interoperability.

ch02.adoc

@@ -20,7 +20,7 @@ In many situations, any integer type may be used.
 When the phrase "integer type" is used in this document, it should be understood to mean **`byte`**, **`unsigned byte`**, **`short`**, **`unsigned short`**, **`int`**, **`unsigned int`**, **`int64`**, or **`unsigned int64`**.
 
 Strings in variables may be represented one of two ways - as atomic strings or as character arrays.
-An n-dimensional array of strings may be implemented as a variable of type **`string`** with n dimensions, or as a variable of type **`char`** with n+1 dimensions where the last (most rapidly varying) dimension is large enough to contain the longest string in the variable.
+An n-dimensional array of strings may be implemented as a variable of type **`string`** with _n_ dimensions, or as a variable of type **`char`** with _n_+1 dimensions, where the most rapidly varying dimension (the last dimension in CDL order) is large enough to contain the longest string in the variable.
 For example, a character array variable of strings containing the names of the months would be dimensioned (12,9) in order to accommodate "September", the month with the longest name.
 The other strings, such as "May", should be padded with trailing NULL or space characters so that every array element is filled.
 If the atomic string option is chosen, each element of the variable can be assigned a string with a different length.

ch07.adoc

@@ -17,7 +17,7 @@ The value of **`bounds`** is the name of the variable that contains the vertices
 We refer to this type of variable as a "boundary variable."
 __A boundary variable must have one more dimension than its associated coordinate or auxiliary coordinate variable.__ 
 We refer to the additional dimension as the "vertex dimension".
-The vertex dimension must be the last dimension in CDL order (the most rapidly varying dimension), and its size is the maximum number of cell vertices.
+The vertex dimension must be the most rapidly varying dimension (the last dimension in CDL order), and its size is the maximum number of cell vertices.
 The vertex dimension must be of size two if the associated variable is one-dimensional, and of size greater than two if the associated variable has more than one dimension.
 For grids constructed from cells that do not all have the same number of sides (e.g., a grid with some rectangular cells and some triangular cells), the vertex dimension must be at least as large as the maximum number of cell vertices.
 For cells with fewer vertices than the size of vertex dimension, the unneeded elements must appear as the last elements in the vertex dimension and must be assigned the **`_FillValue`**.

history.adoc

@@ -7,6 +7,7 @@
 
 === Working version (most recent first)
 
+* {issues}530{Issue #530]: Define "the most rapidly varying dimension", and use this phrase consistently with the clarification "(the last dimension in CDL order)".
 * {issues}163[Issue #163]: Provide a convention for boundary variables for grids whose cells do not all have the same number of sides.
 * {issues}174[Issue #174]: A one-dimensional string-valued variable must not have the same name as its dimension, in order to avoid its being mistaken for a coordinate variable.
 * {issues}237[Issue #237]: Clarify that the character set given in section 2.3 for variable, dimension, attribute and group names is a recommendation, not a requirement.