Custom Query (124 matches)
Results (10 - 12 of 124)
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:
Proposed change:
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. TitleConventions for Point Observation Data 2. ModeratorSteve Hankin 3. RequirementCurrent conventions are oriented towards gridded data. This proposal extends the framework to specify how to encode "point observation" data. 4. Initial Statement of Technical ProposalWe 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
6. Status QuoCurrently sections 5.4 and 5.5 describe 2 examples of point observations (station time series and trajectories). This proposal generalizes those. 7. Detailed ProposalBecause 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:
"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."
"If only one missing value is needed for a variable then we strongly recommend that this value be specified using the _FillValue attribute."
"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."
"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." |