Custom Query (125 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (13 - 15 of 125)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Ticket Resolution Summary Owner Reporter
#74 fixed Allow sharing of ancillary variables among multiple data variables davidhassell rhorne@…
Description

Currently it is not possible for multiple data variables to share an ancillary variable.

Augment the conventions to allow two or more data variables to share an ancillary variable.

Here is an example of a convention, which dovetails with the existing conventions, to provide this capability:

float swpt(lat,lon);

. .

swpt:standard_name="sea_water_potential_temperature"; swpt:ancillary_variables="nobs flags"; . .

float sws(lat,lon);

. . sws:standard_name="sea_water_salinity"; sws:ancillary_variables="nobs flags"; . .

int nobs(lat,lon);

. . nobs:standard_name="sea_water_potential_temperature sea_water_salinity number_of_observations"; . .

int flags(lat,lon);

. . flags:standard_name="sea_water_potential_temperature sea_water_salinity status_flag"; flags:flag_values = 0, 1, 2; flags:flag_meanings = "valid invalid unknown"; . .

Change the text in the CF metadata conventions section 3.3 that reads

"A standard name is associated with a variable via the attribute standard_name which takes a string value comprised of a standard name optionally followed by one or more blanks and a standard name modifier (a string value from Appendix C, Standard Name Modifiers)."

to

"A standard name is associated with a variable via the attribute standard_name which takes a string value that can have either of two forms. The first form is a standard name alone. The second form is a blank-separated list beginning with one or more standard names and ending with a single standard name modifier (i.e. standard_name [standard_name ...] standard_name_modifier). The standard name modifiers are defined in Appendix C, Standard Name Modifiers. This second form permits a single variable to provide ancillary data (see section 3.4) for two or more variables where each has a unique standard name."

Changes to CF software tools are required. For example, the CF_checker, which validates the standard_name attribute needs to change. However, it does not require any change to software that uses the complete attribute simply as an identifying string (e.g. to label plots, etc.)

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

#32 fixed Ambiguity in text discussing auxiliary coordinate variables cf-conventions@… taylor13
Description

I find the antecdents to the various instances of "their" in the following text ambiguous.

"The axis attribute is not allowed for auxiliary coordinate variables. Auxiliary coordinate variables which lie on the horizontal surface can be identified as such by their dimensions being horizontal, which can in turn be inferred from their having an axis attribute of X or Y , or from their units in the case of latitude and longitude (see Chapter 4, Coordinate Types )."

I propose modifying the text slightly to read:

"The axis attribute is not allowed for auxiliary coordinate variables. Auxiliary coordinate variables which lie on the horizontal surface can be identified as such by their dimensions being horizontal. Horizontal dimensions are those whose coordinate variables have an axis attribute of X or Y, or a units attribute indicating latitude and longitude (see Chapter 4, Coordinate Types)."

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