Custom Query (124 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (7 - 9 of 124)

1 2 3 4 5 6 7 8 9 10 11 12 13
Ticket Resolution Summary Owner Reporter
#14 wontfix Allow time coordinates to be stored as a W3C / ISO 8601formatted String cf-conventions@… caron
Description

Currently time coordinates must be stored as a number with units that are parsable by the udunits library (cf section 4.4).

I propose that we also allow time coordinates to be expressed as W3C/ISO 8601 formatted Strings. (Example: 2007-03-29T12:00:00Z) This format is widely used internationally, it is a profile by the W3C of the ISO standard. This page has a summary of the format and more links:

http://www.unidata.ucar.edu/projects/THREDDS/tech/interfaceSpec/NetcdfSubsetService.html#Reference

Reasons:

  • A string representation is human readable (compare with "348472938 secs since 2007-03-29 12:00:00Z")
  • Independence from the udunits library when needed.
  • May be easier to use for some.

Proposed change:

1) Change section 4.4 to start with:

"Date coordinates must either be of type char, formatted according to the W3C/ISO 8601 Date format, or of numeric type with a mandatory units attribute containing a udunit compatible date unit string."

2) Add an appendix that describes the W3C/ISO 8601 format, or simply point to an external link.

Note: I find it clearer to use "date" to refer to "calendar date", and "time" to mean a "unit of time duration" (eg 1500 secs). It might be worth looking through our usage to see where this meaning may be unclear.

#28 wontfix Correct recommended units for lat and lon cf-conventions@… apamment
Description

Beate Geyer has pointed out that the recommended units for latitude and longitude coordinate variables in sections 4.1 and 4.2 of the conventions document are inconsistent with the canonical units published in the standard name table.

Sections 4.1 and 4.2 of the conventions recommend degrees_north and degrees_east for lat and lon, respectively. The standard name table uses the singular form for the canonical units, i.e. degree_north and degree_east. The two sources of documentation should be made consistent. Beate has indicated a preference for the singular form of the unit, therefore it is proposed that the conventions document should be modified to agree with the standard name table. This requires modification to the sentences in sections 4.1 and 4.2 beginning with "The recommended unit ...".

Alison

#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.

1 2 3 4 5 6 7 8 9 10 11 12 13
Note: See TracQuery for help on using queries.