Custom Query (124 matches)


Show under each result:

Results (43 - 45 of 124)

Ticket Resolution Summary Owner Reporter
#105 wontfix Scalar Coordinates cf-conventions@… markh

1. Title

Scalar Coordinates

2. Moderator


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.

#106 invalid aneed additional area_types cf-conventions@… rhorne@…

The GOES-R 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,


#110 invalid test new installation cf-conventions@… painter1

This is a test of the new Trac installation - sorry to bother you!

Note: See TracQuery for help on using queries.