Custom Query (124 matches)


Show under each result:

Results (64 - 66 of 124)

Ticket Resolution Summary Owner Reporter
#70 fixed Connecting coordinates to Grid Mapping variables davidhassell markh


Connecting coordinates to Grid Mapping variables


David Hassell


To allow each Coordinate or Auxiliary Coordinate Variable to be explicitly attached to a particular Grid Mapping Variable.


To define a coordinate reference system, a grid_mapping variable is defined, with variable attributes to define the coordinate reference system attributes.

To define coordinates, be they coordinate variable or auxiliary coordinates, with respect to a coordinate system an enhanced grid_mapping syntax is proposed.

A data variable's grid_mapping attribute may use a syntax, derived from the cell_methods and cell_measures approach. Using this model, the Grid Mapping variable name is stated, followed by a ':' followed by a space separated list of Coordinate names; a name finishing with a ':' indicates a new Grid Mapping variable name, to be followed by the coordinates which are linked to it.


The current grid_mapping attribute syntax is a regressive case of this, so the proposal is backwards compatible. In the case where the grid_mapping attribute contains no ':' then the grid_mapping is defined by the current methodology.

The grid_mapping attribute is interpreted differently if it uses the enhanced syntax, in which case different coordinates may be linked to different Grid Mappings.

Section 5.6 should include the text:

A data variable may link Coordinates and Auxiliary Coordinate Variables to 
Grid Mapping Variables by supplying the name of the Grid Mapping variable, 
a ':' and a space separated list of Coordinate names:

within the data variable's grid_mapping attribute.

Use Case

Consider a file containing a data variable referencing coordinate variables: Easting, Northing, Height (above mean sea level). These are all defined with respect to the Ordnance Survey of Great Britain coordinate reference system, a parametric transverse Mercator with a defined vertical datum.

To be CF compliant I need to include two auxiliary coordinates, latitude and longitude. I can calculate these for a specifically defined coordinate reference system, using the definition of the transverse Mercator projection. I will also include the height with respect to this new datum as an auxiliary_coordinate.

In the example use case then the data variable's grid_mapping attribute would read: "OSGB: Easting Northing Height GeogCS: Lat Lon geogHeight"

  y = 100000 ;
  x = 100000 ;
  z = 100;
  double x(x) ;
    x:standard_name = "projection_x_coordinate" ;
    x:long_name = "Easting"
    x:units = "m" ;
  double y(y) ;
    y:standard_name = "projection_y_coordinate" ;
    y:long_name = "Northing"
    y:units = "m" ;
  double z(z) ;
    y:standard_name = "height_above_reference_ellipsoid" ;
    y:long_name = "height_above_osgb_msl" ;
    y:units = "m" ;
  double lat(y, x) ;
    lat:standard_name = "latitude" ;
    lat:units = "degrees_north" ;
  double lon(y, x) ;
    lon:standard_name = "longitude" ;
    lon:units = "degrees_east" ;
  float temp(y, x) ;
    temp:standard_name = "air_temperature" ;
    temp:units = "K" ;
    temp:coordinates = "lat lon" ;
    temp:grid_mapping = "crsOSGB: x y z GeogCS: lat lon" ;
  float pres(y, x) ;
    temp:standard_name = "air_pressure" ;
    temp:units = "Pa" ;
    temp:coordinates = "lat lon" ;
    temp:grid_mapping = "crsOSGB: x y z GeogCS: lat lon" ;
  int crsOSGB ;
    crs:grid_mapping_name = "transverse_mercator";
    crs:semi_major_axis = 6377563.396 ;
    crs:inverse_flattening = 299.3249646 ;
    crs:latitude_of_projection_origin = 49.0 ;
    crs:longitude_of_projection_origin = -2.0 ;
    crs:false_easting = 400000.0 ;
    crs:false_northing = -100000.0 ;
    crs:scale_factor_at_projection_origin = 0.9996012717 ;
    crs:vert_CS = "Newlyn" ;
    crs:vert_datum = "Ordnance Datum Newlyn, 2005" ;
    crs:unit = "metre" ;
  int crsWGS84 ;
    crs:grid_mapping_name = "latitude_longitude";
    crs:longitude_of_prime_meridian = 0.0 ;
    crs:semi_major_axis = 6378137.0 ;
    crs:inverse_flattening = 298.257223563 ;

#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
#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
Note: See TracQuery for help on using queries.