Custom Query (125 matches)

The GOES-R ground system generates products that conmtains two statistics that are not defined in the current set of cell methods in the CF standard. The two statistics are:

(1) root_mean_square (2) total_sum_of_squares

This trac item requests that these two statistics be added to the set of CF defined cell_methods. The changes to the CF standard required to support this are as follows...

In CF standard paragraph 7.3. Cell Methods, change this sentence:

The values of method should be selected from the list in Appendix E, Cell Methods, which includes point, sum, mean, maximum, minimum, mid_range, standard_deviation, variance, mode, and median.

To:

The values of method should be selected from the list in Appendix E, Cell Methods, which includes point, sum, mean, maximum, minimum, mid_range, standard_deviation, variance, mode, median, root_mean_square, and total_sum_of_squares.

In CF standard Appendix E Cell Methods, add the following two rows to Table E.1 Cell Methods:

(first new row)

cell_methods column: root_mean_square

Units column u

Description column: Root mean square (RMS)

(second new row)

cell_methods column: total_sum_of_squares

Units column u2

Description column: Total sum of squares (TSS)

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 inter-relationships, 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 inter-relationship 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 string-valued 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 space-time coordinate variables will not vary with respect to the instance dimension. These space-time 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 inter-dependency relationships, such as:
  • multiple related time coordinates;
  • model, experiment, run identifiers for multi-model 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.

In section 7.3. Cell Methods there are 3 references to "cell_bounds" that should be "bounds" instead (including one reference in 7.3.2).