Custom Query (125 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (10 - 12 of 125)

1 2 3 4 5 6 7 8 9 10 11 12 13 14
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.

#37 fixed Conventions for Point Observation Data stevehankin caron
Description

1. Title

Conventions for Point Observation Data

2. Moderator

Steve Hankin

3. Requirement

Current conventions are oriented towards gridded data. This proposal extends the framework to specify how to encode "point observation" data.

4. Initial Statement of Technical Proposal

We show six types of point observational data, and describe a general way to encode many variations. The main technical extension is a simple way to describe ragged arrays, for the case when rectangular arrays are too inefficient.

5. Benefits

  • Many data providers would like to use CF conventions when storing their observational data.
  • This will allow a standard for converting things like BUFR data into netCDF.

6. Status Quo

Currently sections 5.4 and 5.5 describe 2 examples of point observations (station time series and trajectories). This proposal generalizes those.

7. Detailed Proposal

Because of the length of this, I have written it as a Microsoft Word file to make it easy to edit. I can reformat later when it is close to being finished.

Some background docs and earlier drafts:

#58 fixed Remove deprecation of "missing_value" attribute cf-conventions@… caron
Description

CF incorrectly deprecates the "missing_value" attribute due to a misunderstanding.

All changes refer to section 2.5.1:

  1. Change the first paragraph from:

"The NUG conventions (NUG section 8.1) provide the _FillValue, valid_min, valid_max, and valid_range attributes to indicate missing data."

to:

"The NUG conventions (NUG section 8.1) provide the _FillValue, missing_value, valid_min, valid_max, and valid_range attributes to indicate missing data."

  1. remove the word "strongly" from this sentence:

"If only one missing value is needed for a variable then we strongly recommend that this value be specified using the _FillValue attribute."

  1. Remove this paragraph:

"The missing_value attribute is considered deprecated by the NUG and we do not recommend its use. However for backwards compatibility with COARDS this standard continues to recognize the use of the missing_value attribute to indicate undefined or missing data."

  1. Change the first sentence of the last paragraph from:

"The missing values of a variable with scale_factor and/or add_offset attributes (see section Section 8.1, “Packed Data”) are interpreted relative to the variable's external values, i.e., the values stored in the netCDF file. "

to:

"The missing values of a variable with scale_factor and/or add_offset attributes (see section Section 8.1, “Packed Data”) are interpreted relative to the variable's external values ( a.k.a. the packed values, the raw values, the values stored in the netCDF file), not the values that result after the scale and offset is applied."

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