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
#51 fixed syntax consistency for dimensionless vertical coordinate definitions cf-conventions@… taylor13
Description

I suggest that for readability and for consistency in the syntax of the definitions of dimensionless vertical coordinates, the following changes be made in the CF documentation.

  1. Where the coordinate definition involves a construction like "for k<=k_c .... for k>k_c ....", follow each "for" phrase with a colon. [This is currently done inconsistently.]
  1. Where the coordinate definition involves a term that is subsequently defined (e.g., the C(k) in the ocean-S coordinate), precede the definition of the term with "where".

These make the definitions easier to read. Note that CF does not mandate storage of the coordinate definitions in the netCDF files, but for CMIP, we store the formulas as a text string attribute attached to the coordinate variable and named "formula".

#89 fixed standard names for vector components davidhassell markh
Description

Objective

A reinterpretation of current standard names to make the identification of vector components clear and able to meet the needs of users.

This issue is related to the proposal on #79

Proposal

To adopt the constrained standard name concept to re-interpret vector quantity standard names, without invalidating any current datasets. This would involve:

  • 'x_' type standard names being valid for all coordinate definitions:
    • '"x" indicates a vector component along the grid x-axis, positive with increasing x.'
  • 'eastward_' type standard names being valid for all 'true east' vectors:
    • '"Eastward" indicates a vector component which is positive when directed eastward (negative westward); where eastward is defined as the grid x-axis direction, this is a constrained version of the "x_" standard name';
    • this may be interpreted in two ways, as:
      1. where eastward is defined as the grid x-axis, this standard name is a constrained version of x_wind
      2. where eastward is not defined as the grid x-axis, this standard name stands independently

This enables data producers to use eastward wind in the same way they currently do, while meeting my requirements, for datasets where x may or may not be east, depending on the location and for data format interoperability with formats which do not have an explicit 'eastward_' phenomenon definition.

It enables datasets to be written where:

  • vector is x but not east
    • standard_name: x_<>
  • vector is x and may be east or eastish
    • standard_name: x_<>
  • vector is x and happens to be always east
    • standard_name: x_<>
  • vector is x constrained to always be east
    • standard_name: eastward_<>
  • vector is east but not x
    • standard_name: eastward_<>

'eastward_<>' is already interpreted in multiple ways, depending on the coordinate variable context of the dataset. 'x_<>' should also be abe to be interpreted based on coordinate variable context, to enable datasets to be encoded which currently cannot be written in a CF compliant fashion

Analogy

This approach, of constraining standard names, is analogous to qualification. For example:

  • there is a standard name of air_pressure
  • this could be defined, for a particular dataset, such that the vertical coordinate indicates that the data is at a surface
  • if the fact that the dataset is at a surface is intrinsic to the data, the qualified (constrained) standard name may be used: surface_air_pressure
#55 fixed specify that CF uses UDUNITS-2 cf-conventions@… jonathan
Description

Unidata has released a new version of the udunits package, which fixes some problems in the original version. Although the units supported are very largely the same, CF should specify which version is the reference standard, since there are a few differences. Unidata deprecates the original version. Therefore version 2 should be the CF reference. This ticket proposes to clarify and update the CF standard by

  • Replacing all references to UDUNITS with UDUNITS-2.
  • Replacing all references to udunits.dat with references to the appropriate xml file of UDUNITS-2.

I'm submitting this as a defect, because I don't think it materially affects the CF standard.

Jonathan Gregory

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