Description 
1. Title
Two new dimensionless vertical coordinates to support ocean models
2. Moderator
Rich Signell
3. Requirement
The ocean modeling community needs two additional vertical coordinate specifications to allow modern scoordinate model output to be CFcompliant and allow more general specification of scoordinate model output for future development.
4. Initial Statement of Technical Proposal
The existing ocean_s_coordinate dimensionless vertical coordinate specification in CF is limited to a specific vertical stretching function and set of control parameters, while modern versions of ROMS allow for more flexible specification. Additional of these two new generalized vertical coordinate specifications would allow output from existing ROMSderived models (and other s coordinate models) to be CFcompliant, as well as allowing more flexibility for future s_coordinate model developers and users to write and read CFcompliant model output.
Here are the proposed additions to Appendix D. Dimensionless Vertical Coordinates
Ocean scoordinate, generic form 1
standard_name = "ocean_s_coordinate_g1"
Definition:
z(n,k,j,i) = S(k,j,i) + eta(n,j,i) * (1 + S(k,j,i) / depth(j,i))
where S(k,j,i) = depth_c * s(k) + (depth(j,i)  depth_c) * C(k)
and where z(n,k,j,i) is the height, positive upwards, relative to
ocean datum (e.g. mean sea level) at gridpoint (n,k,j,i);
eta(n,j,i) is the height of the ocean surface, positive upwards,
relative to ocean datum at gridpoint (n,j,i); s(k) is the
dimensionless coordinate at vertical gridpoint (k) with a
range of 1 <= s(k) <= 0, s(0) corresponds to eta(n,j,i) whereas
s(1) corresponds to depth(j,i); C(k) is the dimensionless vertical
coordinate stretching function at gridpoint (k) with a range of
1 <= C(k) <= 0, C(0) corresponds to eta(n,j,i) whereas
C(1) corresponds to depth(j,i); and the constant depth_c,
(positive value), is a critical depth controlling the stretching.
The format for the formula_terms attribute is
formula_terms = "s: var1 C: var2 eta: var3 depth: var4 depth_c: var5"
Ocean scoordinate, generic form 2
standard_name = "ocean_s_coordinate_g2"
Definition:
z(n,k,j,i) = eta(n,j,i) + (eta(n,j,i) + depth(j,i)) * S(k,j,i)
where S(k,j,i) = (depth_c * s(k) + depth(j,i) * C(k)) / (depth_c + depth(j,i))
and where z(n,k,j,i) is the height, positive upwards, relative to
ocean datum (e.g. mean sea level) at gridpoint (n,k,j,i);
eta(n,j,i) is the height of the ocean surface, positive upwards,
relative to ocean datum at gridpoint (n,j,i); s(k) is the
dimensionless coordinate at vertical gridpoint (k) with a
range of 1 <= s(k) <= 0, s(0) corresponds to eta(n,j,i) whereas
s(1) corresponds to depth(j,i); C(k) is the dimensionless vertical
coordinate stretching function at gridpoint (k) with a range of
1 <= C(k) <= 0, C(0) corresponds to eta(n,j,i) whereas
C(1) correspond to depth(j,i); and the constant depth_c,
(positive value) is a critical depth controlling the stretching.
The format for the formula_terms attribute is
formula_terms = "s: var1 C: var2 eta: var3 depth: var4 depth_c: var5"
5. Benefits
The oceanographic community, especially those producing or consuming products from s coordinate models (e.g. variants and derivatives of the Regional Ocean Modeling System (ROMS)) would benefit from the addition of these two new dimensionless vertical coordinate specifications. These two new coordinates have been exercised in the Unidata Common Data Model and the Unidata NetCDFJava Library for the last two years. It's time to add them officially to the CF Conventions.
6. Status Quo
The only option currently to store modern ROMS results as CF compliant would be to write the entire Z field as a 4D array.

Description 
1. Title
Scalar Coordinates
2. Moderator
unknown
3. Requirement
The ability to store scalar coordinates in CF NetCDF data sets.
Scalar Coordinates are a valuable semantic concept, allowing data variables to encode coordinates which do not vary across the domain of the data variable.
Invariance with respect to the data variable's dimensions is the key characteristic of these coordinates and this is all the meaning that should be explicitly defined for such a coordinate. Further characteristics, such as implied degrees of freedom and potential interrelationships, may be inferred downstream, at the discretion of the data consumer.
The current conventions provides clear specification on vector coordinates, encoded as either Coordinate Variables or Auxiliary Coordinate Variables. Such variables, which may be encoded as not varying with respect to the data variable, can be used wherever it is vital that the interrelationship and degree of freedom are explicitly encoded. The specification does not make it clear enough what is meant by a scalar coordinate variable.
The current conventions document (1.6) does not make it clear whether the scalar coordinate variable (section 5.7) is:
an encoding detail with explicitly no semantic content, merely storing vector coordinates:
where the characteristics of these vector coordinates must be inferred by context;
a semantic container enabling scalar coordinates to be stored and recognised as scalar coordinates.
This interpretation requires clarification, which this proposal aim to deliver. Explicitly, this proposal will define the scalar coordinate variable as a semantic container for coordinate information.
4. Initial Statement of Technical Proposal
1.2 Terminology
A NetCDF variable which contains coordinate information for a data variable, where the coordinate information does not vary with respect to the data variable's dimensions.
5.7 Scalar Coordinate Variables
A scalar coordinate variable defines a coordinate which applies to an entire data variable equally. The scalar coordinate does not vary with respect to the data variable's dimensions.
The scalar coordinate variable is associated with a data variable via the coordinates attribute. The scalar coordinate variable does not share any dimensions with the data variable.
The variable name of a scalar coordinate variable must not match the name of any dimension in the file.
Bounds may be defined for a scalar coordinate variable in the same way as other coordinates.
A scalar coordinate variable may be interpreted as implying a potential further dimension, of size one, for the data variable. However, scalar coordinate variables do not define explicit independent dimensions.
Note that use of scalar coordinate variables for latitude, longitude, vertical, or time coordinates will inhibit COARDS conforming applications from recognizing them.
6.1 Labels
... {Unchanged, up to the last sentence}
If a character variable referenced by a data variable's coordinates attribute has only one dimension, the maximum length of the string, it is a stringvalued scalar coordinate variable (see Section 5.7 Scalar Coordinate Variables).
9.2 Collections, Instances and Elements
... {First two paragraphs unchanged}
If there is only a single feature to be stored in a data variable, the instance dimension may be omitted. In this case the mandatory spacetime coordinate variables will not vary with respect to the instance dimension. These spacetime coordinates, as defined in table 9.1, may need to be defined as scalar coordinate variables, to maintain the required relationships for the feature types.
5. Benefits
The community benefits from this proposal by gaining clarity over the interpretation of scalar coordinate variables as a simple semantic concept within CF with a clear encoding.
All use cases presented to the mailing list to date are supported by this proposal, including:
 encoding of size one explicit coordinate variables as scalar coordinate variables to simplify data variable shape;
 encoding of coordinates where there are multiple possible interdependency relationships, such as:
 multiple related time coordinates;
 model, experiment, run identifiers for multimodel analyses;
 encoding of discrete sampling geometries where there is a single feature;
 encoding of coefficients as coordinates.
The data producer has the opportunity to select a scalar coordinate as the most appropriate way of describing some aspects of their data. The encoding convenience of omitting dimensions of size one is provided for, with a clear recognition that this encoding option slightly limits the richness of expression available with CF vector coordinates.
6. Status Quo
Currently the interpretation of scalar coordinate variables is unclear. It is recognised that a clarification is required. As such the status quo is deemed undesirable (e.g.4, 15)
There is another ticket, #104, proposing an alternative change. These two tickets should not both be approved, they are mutually exclusive.

Description 
The GOESR system generates fire, aerosol, rainfall rate/quantity, and volcanic ash products. These products include summary (aggregate) statistics (min, max, mean, and std deviation) whose formal CDL/NcML specifications make use of the CF "cell_methods" attribute. These statistics are associated with areas where the following environment conditions apply:
(!) fire
(2) smoke
(3) dust
(4) volcanic_ash
(5) raining
The cell_methods attribute associated with these statistics could benefit by using the existing "where" clause that reference of the five environment conditions listed above.
As a result, we would like fire, smoke, dust, volcanic_ash, and raining to the area_type table.
very respectfully,
randy
