Custom Query (125 matches)


Show under each result:

Results (76 - 78 of 125)

Ticket Resolution Summary Owner Reporter
#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
#92 fixed Add oblique mercator projection davidhassell mcginnis

The Oblique Mercator projection is used by at least one regional climate model, RegCM3, which is part of the NARCCAP climate modeling program. Currently we record its map projection information using the transverse_mercator projection, which I have learned is very similar but not quite the same. I propose to add this map projection so we can get it right.

Proposed text:

Oblique Mercator

grid_mapping_name = oblique_mercator

Map parameters:

  • azimuth
  • latitude_of_projection_origin
  • longitude_of_projection_origin
  • scale_factor_at_projection_origin
  • false_easting
  • false_northing

Map coordinates:

The x (abscissa) and y (ordinate) rectangular coordinates are identified by the standard_name attribute value projection_x_coordinate and projection_y_coordinate respectively.


Notes on using the PROJ.4 software package for computing the mapping may be found at . The Rotated Mercator projection is an Oblique Mercator projection with azimuth = +90.

If adding a new attribute for azimuth is problematic, this proposal could be modified to add the rotated_mercator projection instead, which is a special case of Oblique Mercator with azimuth = 90.

Note that apparently there is a subtle technical difference between an Oblique Mercator projection and a Hotine Oblique Mercator projection that depends on when the rectification from skew grid to map grid is applied. Since most mapping packages don't support a rectified grid angle parameter at all (effectively giving it a default value of 90 degrees, such that it has no effect), to avoid unnecessary proliferation of attributes I propose to omit this parameter and elide this distinction until such time as it proves necessary.

My knowledge of this topic is quite limited; I have made this proposal based on what understanding I have gleaned from the geotiff website and communications with colleagues working with our RegCM3 output in GIS. Commentary from experts would be very welcome.

Note: See TracQuery for help on using queries.