Custom Query (125 matches)


Show under each result:

Results (49 - 51 of 125)

Ticket Resolution Summary Owner Reporter
#89 fixed standard names for vector components davidhassell markh


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


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


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
#88 fixed Terms of Reference for the CF Data Model davidhassell markh


The purpose of this ticket is to agree the scope and terms of reference for the CF data model.


Scope, Terms and Conditions

  1. The CF community will adopt a data model as part of the CF Metadata Project.
  2. The data model will be a complementary resource to the:
    • CF Conventions Document
    • CF Standard Name Table
    • CF Conformance Requirements & Recommendations
    • Guidelines for Construction of CF Standard Names
  3. The data model will be maintained by the community, using the same mechanisms as are used for the conventions, conformance and standard_name documents.
  4. The data model, once it has reached v1.0, will be consistent with the CF Conventions Document.
    • This consistency will be maintained.
      • Changes to the specification should be evaluated to determine whether they are consistent with the data model: if inconsistencies exist, these should be addressed, either by altering the specification change proposal or by proposing a change to the data model.
  5. The scope of the data model is to define the concepts of CF and the relationships that exist between these concepts.
  6. The data model provides a logical abstraction of the concepts defined by CF, independent of implementation details.
  7. The data model does not define the interface to CF.


The data model is believed to offer the following benefits providing:

  • an orientation guide to the CF Conventions Document
  • a guide to the development of software compatible with CF
  • a reference point for gap analysis and conflict analysis of the CF specification
  • a communication tool for discussing CF concepts and proposals for changes to the CF specification
#87 fixed Allow comments in coordinate variables davidhassell ngalbraith

Appendix A, Attributes, indicates that the 'comment' attribute may be used as a global attribute or for non-coordinate data variables. Its description states that it is for 'Miscellaneous information about the data or methods used to produce it.'

For in situ ocean data, certain information about the coordinate variables seems to belong in a comment; coordinate values have characteristics that should be described, but there are no standards for these descriptions yet.

For example, for a surface mooring, this seems like the best place to indicate whether the latitude and longitude are the surveyed anchor position or a GPS fix from the buoy itself, and whether the depth is the combined length of line/chain/instrument cases between the surface and the sensor, or a calculated depth based on measured pressure.

So, I propose that in the table in Appendix A we change the 'Use' of the comment attribute from G,D to G,C,D, to allow comments for variables containing coordinate data.


Note: See TracQuery for help on using queries.