Custom Query (125 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (40 - 42 of 125)

Ticket Resolution Summary Owner Reporter
#109 fixed resolve inconsistency of positive and standard_name attributes davidhassell jonathan
Description

John Graybeal raised the question of what happens if the positive and standard_name attributes of a vertical coordinate variable are inconsistent according to the definition of the latter e.g. if positive="up" and standard_name="depth", which is defined as vertical distance below the surface, implying that positive is down. Steve Hankin and I discussed this on the CF email list and further by email and phone. We would like to propose the following clarification, which should answer the question without materially changing the convention or invalidating existing data.

Append the following to the last paragraph (beginning "Optionally") of introductory part of Section 4.3 (before Section 4.3.1):

If both positive and standard_name are provided, it is recommended that they should be consistent. For instance, if a depth of 1000 metres is represented by -1000 and positive is up, it would be inconsistent to give the standard_name as depth, whose definition (vertical distance below the surface) implies positive down. If an application detects such an inconsistency, the user should be warned, and the positive attribute should be used to determine the sign convention.

Insert the following into Section 4.3 of the conformance document:

Recommendations:

The positive attribute should be consistent with the sign convention implied by the definition of the standard_name, if both are provided.

There is no general way to check consistency at present.

Jonathan

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

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,

randy

#105 wontfix Scalar Coordinates cf-conventions@… markh
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 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.

Note: See TracQuery for help on using queries.