David Hassell and I propose the following changes to the CF standard document to clarify the interpretation of scalar coordinate variables. We do not think this is a material change to the convention, which already implies this interpretation, and we believe this interpretation is what was intended when scalar coordinate variables were introduced.

Section 5.7, Scalar coordinate variables.

The convention contains the following sentences:

Under COARDS the method of providing a single valued coordinate was to add a dimension of size one to the variable, and supply the corresponding coordinate variable. The new scalar coordinate variable is a convenience feature which avoids adding size one dimensions to variables. Scalar coordinate variables have the same information content and can be used in the same contexts as a size one coordinate variable.

These sentences are OK as they stand, we think, but it would be better to describe the current situation without emphasising its history, so we would propose to replace them with the following. In addition, we propose to add a bit extra, as shown, to the second sentence below:

The use of scalar coordinate variables is a convenience feature which avoids adding size one dimensions to variables. A scalar coordinate variable has the same information content and can be used in the same contexts as a size one coordinate variable, if numeric, or a size one auxiliary coordinate variable, if a string (Section 6.1).

The next sentence would be unchanged; it mentions how this situation relates to that of the COARDS convention.

At the end of the section, after the example, we propose to append the following sentences:

If a data variable has two or more scalar coordinate variables, they are regarded as though they were all independent coordinate variables with dimensions of size one. If two or more single-valued coordinates are not independent, but have related values (for instance, time and forecast period, or vertical coordinate and model level number, Section 6.2), they should be stored as coordinate or auxiliary coordinate variables of the same size one dimension, not as scalar coordinate variables.

We think the above interpretation and implications are consistent with the convention already, which says in this section that, "Scalar coordinate variables have the same information content and can be used in the same contexts as a size one coordinate variable". However, it would be an improvement to spell it out.

Section 6.1, Labels

Replace the last sentence

If a character variable has only one dimension (the maximum length of the string), it is regarded as a string-valued scalar coordinate variable, analogous to a numeric scalar coordinate variable (see Section 5.7, Scalar Coordinate Variables).

with

If a character variable has only one dimension (the maximum length of the string), it is a string-valued scalar coordinate variable (see Section 5.7, Scalar Coordinate Variables). As such, it has the same information content and can be used in the same contexts as a string-valued auxiliary coordinate variable of a size one dimension. This is a convenience feature which avoids adding the size one dimension to the data variable.

The last part is a repetition of what Section 5.7 says. The reason for the change is that the existing wording is careless in implying that a string could be a coordinate variable; in fact, this is not possible, since string- value coordinates must be auxiliary coordinate variables.

The interpretation of scalar coordinate variables in Section 9 may be different from the above, and this may require further clarification if the above is agreed.

1. Title

Clarifying the role of attributes on boundary variables.

2. Moderator

TBC (any offer will be gladly accepted).

3. Requirement

To disallow inconsistencies between particular attributes of a boundary variable and its associated coordinate or auxiliary coordinate variable.

For example, it is currently possible for a boundary variable to have a different standard_name attribute to its associated coordinate or auxiliary coordinate variable. This would be unsatisfactory because the user of the data cannot know which of the possibilities is correct.

It is proposed that if a boundary variable has attributes which determine the coordinate type (units, standard_name, axis and positive) or those which affect the interpretation of the boundary variable array values (units, calendar, leap_month, leap_year and month_lengths) then they must always agree exactly with the same attributes of its associated coordinate or auxiliary coordinate variable. In addition, it is recommended that these attributes are not provided to a boundary variable since they are already inherited implicitly.

No restriction is made on any other boundary variable attributes.

This does not affect datasets encoded with previous versions of CF

4. Initial Statement of Technical Proposal

The following changes should be made to section 7.1. Cell Boundaries (additions marked by TEXT, deletions by TEXT):

To represent cells we add the attribute bounds to the appropriate coordinate variable(s). The value of bounds is the name of the variable that contains the vertices of the cell boundaries. We refer to this type of variable as a "boundary variable". A boundary variable will have one more dimension than its associated coordinate or auxiliary coordinate variable. The additional dimension should be the most rapidly varying one, and its size is the maximum number of cell vertices. Since a boundary variable is considered to be part of a coordinate variable's metadata, it is not necessary to provide it with attributes (such as long_name and units). and providing no attributes is always acceptable. Boundary variable attributes which determine the coordinate type (units, standard_name, axis and positive) or those which affect the interpretation of the array values (units, calendar, leap_month, leap_year and month_lengths) must always agree exactly with the same attributes of its associated coordinate or auxiliary coordinate variable. To avoid duplication, however, it is recommended that the attributes units, standard_name, axis, positive, calendar, leap_month, leap_year and month_lengths are not provided to a boundary variable.

In section 7.1 Cell Boundaries of the conformance document (additions marked by TEXT, deletions by TEXT):

• Requirements:
  • The type of the bounds attribute is a string whose value is a single variable name. The specified variable must exist in the file.
  • A boundary variable must have the same dimensions as its associated variable, plus have a trailing dimension (CDL order) for the maximum number of vertices in a cell.
  • A boundary variable must be a numeric data type.
  • If a boundary variable has units or standard_name attributes, they must agree with those of its associated variable. units, standard_name, axis, positive, calendar, leap_month, leap_year and month_lengths attributes, they must agree exactly with those of its associated variable.

• Recommendations:
  • The points specified by a coordinate or auxiliary coordinate variable should lie within, or on the boundary, of the cells specified by the associated boundary variable.
  • Boundary variables should not have the _FillValue or missing_value _FillValue, missing_value, units, standard_name, axis, positive, calendar, leap_month, leap_year or month_lengths attributes.

5. Benefits

It would be disallowed to encode type-determining attributes (units, calendar, standard_name, axis and positive) or array value interpretation attirbutes (units, calendar, leap_month, leap_year and month_lengths) on a boundary variable if they conflict with the associated coordinate or auxiliary coordinate variable.

6. Status Quo

Attributes on a boundary variable may conflict with the associated coordinate or auxiliary coordinate variable, and this is not always checked by the CF checker.

This proposal does not affect datasets encoded under previous versions of CF, other than via the potential for extra warnings being raised by the CF checker.

David Hassell

Title

Connecting coordinates to Grid Mapping variables

Moderator

David Hassell

Requirement

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

Proposal

To define a coordinate reference system, a grid_mapping variable is defined, with variable attributes to define the coordinate reference system attributes. ​http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.5/ch05s06.html

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.

GRID_MAPPING_VAR: COORD_VAR [COORD_VAR ...] [GRID_MAPPING_VAR: ...]

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:
  
GRID_MAPPING_VAR: COORD_VAR [COORD_VAR ...] [GRID_MAPPING_VAR: ...]

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"

dimensions:
  y = 100000 ;
  x = 100000 ;
  z = 100;
variables:
  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 ;