Connecting coordinates to Grid Mapping variables

[markh]

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 ;

[markh]

I apologise, the example cdl has a couple of errors in it, please use this for reference instead:

dimensions:
  z = 100;
  y = 100000 ;
  x = 100000 ;
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(z, y, x) ;
    temp:standard_name = "air_temperature" ;
    temp:units = "K" ;
    temp:coordinates = "lat lon" ;
    temp:grid_mapping = "crsOSGB: x y z crsWGS84: lat lon" ;
  float pres(z, y, x) ;
    temp:standard_name = "air_pressure" ;
    temp:units = "Pa" ;
    temp:coordinates = "lat lon" ;
    temp:grid_mapping = "crsOSGB: x y z crsWGS84: 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 ;

(I will request that the ticket description is updated to remove the errors)

[jonathan]

Dear Mark

Thanks for making this proposal. It is evident from your use-case that the current grid_mapping convention is not sufficient, because the two coordinate systems use different ellipsoids. This implies that latitude and longitude according to OSGB are not the same as latitude and longitude according to your geographic coordinate system, which I presume to be WGS84, from the name you give it. Is that right? It's possible you might also want to record OSGB latitude and longitude in the file, and that would make the use-case more compelling, I think, as you have to indicate which coord ref system each aux coord belongs to. The example would look like this:

dimensions:
  z = 100;
  y = 100000 ;
  x = 100000 ;
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 latOSGB(y, x) ;
    lat:standard_name = "latitude" ;
    lat:units = "degrees_north" ;
  double lonOSGB(y, x) ;
    lon:standard_name = "longitude" ;
    lon:units = "degrees_east" ;
  double latWGS84(y, x) ;
    lat:standard_name = "latitude" ;
    lat:units = "degrees_north" ;
  double lonWGS84(y, x) ;
    lon:standard_name = "longitude" ;
    lon:units = "degrees_east" ;
  float temp(z, y, x) ;
    temp:standard_name = "air_temperature" ;
    temp:units = "K" ;
    temp:coordinates = "latOSGB lonOSGB latWGS84 lonWGS84" ;
    temp:grid_mapping = "crsOSGB: x y z latOSGB lonOSGB crsWGS84: latWGS84 lonWGS84" ;
  float pres(z, y, x) ;
    temp:standard_name = "air_pressure" ;
    temp:units = "Pa" ;
    temp:coordinates = "latOSGB lonOSGB latWGS84 lonWGS84" ;
    temp:grid_mapping = "crsOSGB: x y z latOSGB lonOSGB crsWGS84: latWGS84 lonWGS84" ;
  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: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 ;

In the above, I have removed the attributes for the vertical coordinate system, as these are not currently in the CF standard, though they could be the subject of another ticket if they are needed.

I'd suggest that we need more detail about how to amend the text. I propose we replace the first paragraph of 5.6 with the following text. It is clearer to show the whole paragraph, although not all of it is changed. In the below, the new or modified text is bold:

When the coordinate variables for a horizontal grid are not longitude and latitude, it is required that the true latitude and longitude coordinates be supplied via the coordinates attribute. If in addition it is desired to describe the mapping between the given coordinate variables and the true latitude and longitude coordinates, or to describe the figure of the Earth used to define the latitude and longitude coordinates, a grid mapping variable is required. Such a variable provides the description of the mapping via a collection of attached attributes. It is of arbitrary type since it contains no data. Its purpose is to act as a container for the attributes that define the mapping. The one attribute that all grid mapping variables must have is grid_mapping_name, which takes a string value that contains the mapping's name. The other attributes that define a specific mapping depend on the value of grid_mapping_name. The valid values of grid_mapping_name along with the attributes that provide specific map parameter values are described in Appendix F, Grid Mappings.

The grid mapping variables are associated with the data and coordinate variables by the grid_mapping attribute. This attribute is attached to data variables so that variables with different mappings may be present in a single file. The attribute takes a string value with two possible formats. In the first format, it is a single word, which names a grid mapping variable. In the second format, it is a blank-separated list of words "grid_mapping_variable: coordinate_variable [coordinate_variable ...] [grid_mapping_variable: ...]", which identifies one or more grid mapping variables, and with each grid mapping associates one or more coordinate_variables i.e. coordinate variables or auxiliary coordinate variables. The second form is required if there is a need to distinguish coordinate information that is defined with respect to different projections or reference ellipsoids, but a coordinate variable or auxiliary coordinate variable may be associated with more than one grid mapping if required, for instance if two different projections were defined from the same latitude-longitude coordinate system.

Would you agree with all that?

To complete the proposal, we also need to say exactly what changes would be needed to the conformance requirements, which the CF checker follows.

Best wishes

Jonathan

[markh]

Replying to jonathan:

I'd suggest that we need more detail about how to amend the text. I propose we replace the first paragraph of 5.6 with the following text. It is clearer to show the whole paragraph, although not all of it is changed. In the below, the new or modified text is bold:

When the coordinate variables for a horizontal grid are not longitude and latitude, it is required that the true latitude and longitude coordinates be supplied via the coordinates attribute. If in addition it is desired to describe the mapping between the given coordinate variables and the true latitude and longitude coordinates, or to describe the figure of the Earth used to define the latitude and longitude coordinates, a grid mapping variable is required. Such a variable provides the description of the mapping via a collection of attached attributes. It is of arbitrary type since it contains no data. Its purpose is to act as a container for the attributes that define the mapping. The one attribute that all grid mapping variables must have is grid_mapping_name, which takes a string value that contains the mapping's name. The other attributes that define a specific mapping depend on the value of grid_mapping_name. The valid values of grid_mapping_name along with the attributes that provide specific map parameter values are described in Appendix F, Grid Mappings.

This looks sensible to me, clearly offering the required extension.

The grid mapping variables are associated with the data and coordinate variables by the grid_mapping attribute. This attribute is attached to data variables so that variables with different mappings may be present in a single file. The attribute takes a string value with two possible formats. In the first format, it is a single word, which names a grid mapping variable. In the second format, it is a blank-separated list of words "grid_mapping_variable: coordinate_variable [coordinate_variable ...] [grid_mapping_variable: ...]", which identifies one or more grid mapping variables, and with each grid mapping associates one or more coordinate_variables i.e. coordinate variables or auxiliary coordinate variables. The second form is required if there is a need to distinguish coordinate information that is defined with respect to different projections or reference ellipsoids, but a coordinate variable or auxiliary coordinate variable may be associated with more than one grid mapping if required, for instance if two different projections were defined from the same latitude-longitude coordinate system.

This seems to clearly define the scope, and the syntax to use. As with other parts of the convention, an example is very useful, say:

  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" ;

Would you agree with all that?

yes

To complete the proposal, we also need to say exactly what changes would be needed to the conformance requirements, which the CF checker follows.

The changes appear additive to me, as the current grid_mapping syntax is retained as is.

An extra case is required to identify the 2nd syntax, the inclusion of spaces in the attribute value seems to be the sign that this has occurred.

In this case, the coordinates and grid mapping variables named should be cross checked to ensure that they exist within the file.

I think this is all that is required of the checker, is this right?

[jonathan]

Dear Mark

Quite right, we need an example. The one you gave seems fine to me, but we could even include the much longer version of it that appears earlier. Have I understood correctly that there might be two sets of lat and lon in the file?

For the conformance doc, I agree, the additions are small. We just need some statements in the form of rules, for requirements and recommendations to be checked, like the existing text of the conformance doc.

Cheers

Jonathan

[markh]

Suggested Additional text for the conformance document:

The type of the grid_mapping attribute is a string whose value is of the following form:

 

 grid_mapping_name[: coord_var [coord_var ... [grid_mapping_name: [coord_var ...] ...]]



where brackets indicate optional words.  The grid_mapping_name is the name of a variable and must exist in the file.

The valid values for coord_var are names of coordinate variables in the file.

[markh]

Replying to jonathan:

Dear Mark

Quite right, we need an example. The one you gave seems fine to me, but we could even include the much longer version of it that appears earlier.

I think that perhaps the longer example is a better illustration of the use case, so I would agree that this one would be helpful to have in the conventions document

Is there a source version of the conventions document that I can use to propose the final changes in?

How may we manage this change getting into the conventions document?

[jonathan]

Dear Mark

The text for the conformance document is good, but to be clear we should explain where it goes and how it relates to the existing text. I would say:

In section 5.6 of the conformance document, replace the existing two bullets

• The type of the grid_mapping attribute is a string whose value is a single variable name.
• The specified variable name (known as a grid mapping variable) must exist in the file.

with

• The type of the grid_mapping attribute is a string whose value is of the following form, in which brackets indicate optional text:

     grid_mapping_name[: coord_var [coord_var ...]] [grid_mapping_name: [coord_var ... ]]
  

  Note that in its simplest form the attribute comprises just a grid_mapping_name as a single word.
• Each grid_mapping_name is the name of a variable (known as a grid mapping variable), which must exist in the file.
• Each coord_var is the name of a coordinate variable or auxiliary coordinate variable, which must exist in the file.

In the remaining bullets of this section of the conformance document, replace "grid mapping variable" (singular) with "grid mapping variables" (plural).

Jonathan

[markh]

On this basis, I would like to restate the proposal in its final form:

The CF specification should change as follows.

Replace the first paragraph of 5.6 with the following text: (It is clearer to show the whole paragraph, although not all of it is changed. In the below, the new or modified text is bold:)

When the coordinate variables for a horizontal grid are not longitude and latitude, it is required that the true latitude and longitude coordinates be supplied via the coordinates attribute. If in addition it is desired to describe the mapping between the given coordinate variables and the true latitude and longitude coordinates, or to describe the figure of the Earth used to define the latitude and longitude coordinates, a grid mapping variable is required. Such a variable provides the description of the mapping via a collection of attached attributes. It is of arbitrary type since it contains no data. Its purpose is to act as a container for the attributes that define the mapping. The one attribute that all grid mapping variables must have is grid_mapping_name, which takes a string value that contains the mapping's name. The other attributes that define a specific mapping depend on the value of grid_mapping_name. The valid values of grid_mapping_name along with the attributes that provide specific map parameter values are described in Appendix F, Grid Mappings.

The grid mapping variables are associated with the data and coordinate variables by the grid_mapping attribute. This attribute is attached to data variables so that variables with different mappings may be present in a single file. The attribute takes a string value with two possible formats. In the first format, it is a single word, which names a grid mapping variable. In the second format, it is a blank-separated list of words "grid_mapping_variable: coordinate_variable [coordinate_variable ...] [grid_mapping_variable: ...]", which identifies one or more grid mapping variables, and with each grid mapping associates one or more coordinate_variables i.e. coordinate variables or auxiliary coordinate variables. The second form is required if there is a need to distinguish coordinate information that is defined with respect to different projections or reference ellipsoids, but a coordinate variable or auxiliary coordinate variable may be associated with more than one grid mapping if required, for instance if two different projections were defined from the same latitude-longitude coordinate system.

Example 5.10. British National Grid

dimensions:
  z = 100;
  y = 100000 ;
  x = 100000 ;
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 latOSGB(y, x) ;
    lat:standard_name = "latitude" ;
    lat:units = "degrees_north" ;
  double lonOSGB(y, x) ;
    lon:standard_name = "longitude" ;
    lon:units = "degrees_east" ;
  double latWGS84(y, x) ;
    lat:standard_name = "latitude" ;
    lat:units = "degrees_north" ;
  double lonWGS84(y, x) ;
    lon:standard_name = "longitude" ;
    lon:units = "degrees_east" ;
  float temp(z, y, x) ;
    temp:standard_name = "air_temperature" ;
    temp:units = "K" ;
    temp:coordinates = "latOSGB lonOSGB latWGS84 lonWGS84" ;
    temp:grid_mapping = "crsOSGB: x y z latOSGB lonOSGB crsWGS84: latWGS84 lonWGS84" ;
  float pres(z, y, x) ;
    temp:standard_name = "air_pressure" ;
    temp:units = "Pa" ;
    temp:coordinates = "latOSGB lonOSGB latWGS84 lonWGS84" ;
    temp:grid_mapping = "crsOSGB: x y z latOSGB lonOSGB crsWGS84: latWGS84 lonWGS84" ;
  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: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 ;

[caron]

Hi all:

It seems like the main purpose is to allow specifying lat/lon coordinates using more than one CRS? More generally, to allow specifying x,y coordinates for more than one CRS? Mark, can you say more about your specific need? Is it just lat/lon or also you need to specify multiple projections?

1) This brings up an unstated assumption in the current convention, namely that 2D lat/lon coordinates are in the same CRS as the projection. Not sure if we should make that a stated assumption.

2) "The second form is required if there is a need to distinguish coordinate information that is defined with respect to different projections or reference ellipsoids, but a coordinate variable or auxiliary coordinate variable may be associated with more than one grid mapping if required, for instance if two different projections were defined from the same latitude-longitude coordinate system."

Im not sure if im parsing this correctly. is it the same as:

"The second form is required if one wants to store coordinate information for more than one coordinate reference system."

or is there more to it?

3) What is the relationship to the coordinates listed in the grid_mapping to the coordinates listed in the "coordinates" attribute? Presumably a subset, as long as you include the coordinate variables if not explicitly listed in the "coordinates" attribute.

4) There is an implication, i assume, that the coordinates listed in one of the grid_mapping's are related in the following way: The grid_mapping defines a transformation from the x,y projection coordinates (if present) to the lat/lon coordinates (must be present(?)). When x,y projection coordinates are not present, then the grid_mapping defines an alternate CRS for the lat/lon coordinates.

In this last, im just trying to clarify what semantic content these [grid_mapping_variable: ...] have to have.

John

[markh]

Replying to caron:

Hi all:

Hello John

It seems like the main purpose is to allow specifying lat/lon coordinates using more than one CRS? More generally, to allow specifying x,y coordinates for more than one CRS? Mark, can you say more about your specific need? Is it just lat/lon or also you need to specify multiple projections?

The specific need I have identified is to enable coordinates to be explicitly linking to the relevant CRS. This is done through the data variable, which may be defined with respect to multiple CRSs.

The use case presented is where a projected CRS is defined with respect to a datum which it would be unusual to use for a geographic CRS. The latitude and longitude coordinates required by CF would be much more useful if defined with respect to a more conventional datum.

1) This brings up an unstated assumption in the current convention, namely that 2D lat/lon coordinates are in the same CRS as the projection. Not sure if we should make that a stated assumption.

If this assumption exists for the current syntax, perhaps it should be stated:

2D Latitude and Longitude Coordinates for a projected CRS use the same geographic CRS as the projection is projected from unless otherwise defined.

2) "The second form is required if there is a need to distinguish coordinate information that is defined with respect to different projections or reference ellipsoids, but a coordinate variable or auxiliary coordinate variable may be associated with more than one grid mapping if required, for instance if two different projections were defined from the same latitude-longitude coordinate system." Im not sure if im parsing this correctly. is it the same as: "The second form is required if one wants to store coordinate information for more than one coordinate reference system." or is there more to it?

I am not convinced that a coordinate variable or auxiliary coordinate variable may be associated with more than one grid mapping is really required by the use cases I am aware of.

I may prefer your wording (with a subtle change): The [expanded form of the grid_mapping attribute] is required if one wants to store coordinate information for more than one coordinate reference system.

3) What is the relationship to the coordinates listed in the grid_mapping to the coordinates listed in the "coordinates" attribute? Presumably a subset, as long as you include the coordinate variables if not explicitly listed in the "coordinates" attribute.

I think this is assumed, which may not be sensible. A statement:

All coordinates listed in the grid_mapping attribute must be coordinate variables or auxiliary coordinates of the data variable.

could be added to the specification, and the conformance guidelines.

4) There is an implication, i assume, that the coordinates listed in one of the grid_mapping's are related in the following way: The grid_mapping defines a transformation from the x,y projection coordinates (if present) to the lat/lon coordinates (must be present(?)). When x,y projection coordinates are not present, then the grid_mapping defines an alternate CRS for the lat/lon coordinates.

In this last, im just trying to clarify what semantic content these [grid_mapping_variable: ...] have to have.

I think I would phrase this that a grid_mapping variable defines a coordinate reference system, which coordinates are defined with respect to.

I think this captures the intent of your statement, do you agree?

many thanks for all the input

mark

[caron]

Hi mark:

Replying to markh:

Replying to caron:

Hi all:

Hello John

It seems like the main purpose is to allow specifying lat/lon coordinates using more than one CRS? More generally, to allow specifying x,y coordinates for more than one CRS? Mark, can you say more about your specific need? Is it just lat/lon or also you need to specify multiple projections?

The specific need I have identified is to enable coordinates to be explicitly linking to the relevant CRS. This is done through the data variable, which may be defined with respect to multiple CRSs.

The use case presented is where a projected CRS is defined with respect to a datum which it would be unusual to use for a geographic CRS. The latitude and longitude coordinates required by CF would be much more useful if defined with respect to a more conventional datum.

Can you say more of your specific use case? In principle, an application could take the lat/lon on some datum and recompute them onto some other, more desirable datum, without needing them to be stored in the file.

1) This brings up an unstated assumption in the current convention, namely that 2D lat/lon coordinates are in the same CRS as the projection. Not sure if we should make that a stated assumption.

If this assumption exists for the current syntax, perhaps it should be stated:

2D Latitude and Longitude Coordinates for a projected CRS use the same geographic CRS as the projection is projected from unless otherwise defined.

This implies that the lat/lon coordinates on the same CRS as the projection is optional. Eg, one could instead give the lat/lon of some preferred datum. Is that what you intend?

2) "The second form is required if there is a need to distinguish coordinate information that is defined with respect to different projections or reference ellipsoids, but a coordinate variable or auxiliary coordinate variable may be associated with more than one grid mapping if required, for instance if two different projections were defined from the same latitude-longitude coordinate system." Im not sure if im parsing this correctly. is it the same as: "The second form is required if one wants to store coordinate information for more than one coordinate reference system." or is there more to it?

I am not convinced that a coordinate variable or auxiliary coordinate variable may be associated with more than one grid mapping is really required by the use cases I am aware of.

im not sure i understand that

I may prefer your wording (with a subtle change): The [expanded form of the grid_mapping attribute] is required if one wants to store coordinate information for more than one coordinate reference system.

seems good to me

3) What is the relationship to the coordinates listed in the grid_mapping to the coordinates listed in the "coordinates" attribute? Presumably a subset, as long as you include the coordinate variables if not explicitly listed in the "coordinates" attribute.

I think this is assumed, which may not be sensible. A statement:

All coordinates listed in the grid_mapping attribute must be coordinate variables or auxiliary coordinates of the data variable.

could be added to the specification, and the conformance guidelines.

that seems clear to me.

4) There is an implication, i assume, that the coordinates listed in one of the grid_mapping's are related in the following way: The grid_mapping defines a transformation from the x,y projection coordinates (if present) to the lat/lon coordinates (must be present(?)). When x,y projection coordinates are not present, then the grid_mapping defines an alternate CRS for the lat/lon coordinates.

In this last, im just trying to clarify what semantic content these [grid_mapping_variable: ...] have to have.

I think I would phrase this that a grid_mapping variable defines a coordinate reference system, which coordinates are defined with respect to.

I think this captures the intent of your statement, do you agree?

it might, but im not sure if most data providers would understand it. im not sure if i do. could you expand it a little for the less savvy?

many thanks for all the input

mark

you're welcome.

john

[jonathan]

Dear John and Mark

Thanks for working on this. I am one of the non-savvy regarding coordinate reference systems; in fact, that phrase scares me a bit. Is the proposed text quite correct: "The [expanded form of the grid_mapping attribute] is required if one wants to store coordinate information for more than one coordinate reference system"? The existing form of the attribute is used to relate a projection (or some other transformation such as rotated pole) and a lat-lon (geographical) coordinate system. That is two coordinate systems, but the expanded form is not needed. The expanded form is needed if you have two or more projections/transformations, or two or more horizontal datums (ellipsoid, etc.). Is that right?

Cheers

Jonathan

[markh]

Replying to jonathan:

Dear John and Mark

Thanks for working on this. I am one of the non-savvy regarding coordinate reference systems; in fact, that phrase scares me a bit. Is the proposed text quite correct: "The [expanded form of the grid_mapping attribute] is required if one wants to store coordinate information for more than one coordinate reference system"? The existing form of the attribute is used to relate a projection (or some other transformation such as rotated pole) and a lat-lon (geographical) coordinate system. That is two coordinate systems, but the expanded form is not needed. The expanded form is needed if you have two or more projections/transformations, or two or more horizontal datums (ellipsoid, etc.). Is that right?

Cheers

Jonathan

I think that characterisation is right.

A transformation is always between two things; in the current scope one of these is implicit, and a transformation thus defines the other. By clarifying what is implicit and allowing extension of the syntax to support two (or more) explicit definitions we add required capability and remove some potential confusion.

[markh]

Replying to caron:

Can you say more of your specific use case? In principle, an application could take the lat/lon on some datum and recompute them onto some other, more desirable datum, without needing them to be stored in the file.

This is true, an application could do this, but a data producer cannot encode this information. It appears an odd imbalance if the data producer can only encode latitude and longitude data on the datum from which a projection or transform is defined from.

Another example is where a set of coordinates are used which do not have a mathematical transform to another set. An arbitrarily defined coordinate system may have a 'model coordinate system' with 'x' and 'y' coordinates with each cell mapping to a defined latitude and longitude value pair.

The latitude and longitude are defined with respect to a grid_mapping variable, but the x and y are not, so the data variable's grid_mapping attribute should unambiguously define that the only coordinates which use the grid_mapping are latitude and longitude.

This implies that the lat/lon coordinates on the same CRS as the projection is optional. Eg, one could instead give the lat/lon of some preferred datum. Is that what you intend?

absolutely

I am not convinced that a coordinate variable or auxiliary coordinate variable may be associated with more than one grid mapping is really required by the use cases I am aware of.

im not sure i understand that

I am highlighting that that particular piece of text giving the capability to link one coordinate to multiple grid_mappings is not a required capability, and may do harm.

2) "The second form is required if there is a need to distinguish coordinate information that is defined with respect to different projections or reference ellipsoids, but a coordinate variable or auxiliary coordinate variable may be associated with more than one grid mapping if required, for instance if two different projections were defined from the same latitude-longitude coordinate system." Im not sure if im parsing this correctly. is it the same as: "The second form is required if one wants to store coordinate information for more than one coordinate reference system." or is there more to it?

your final statement is the essence of the requirement.

[markh]

Replying to markh:

Replying to caron:

Can you say more of your specific use case? In principle, an application could take the lat/lon on some datum and recompute them onto some other, more desirable datum, without needing them to be stored in the file.

This is true, an application could do this, but a data producer cannot encode this information. It appears an odd imbalance if the data producer can only encode latitude and longitude data on the datum from which a projection or transform is defined from.

Another example is where a set of coordinates are used which do not have a mathematical transform to another set. An arbitrarily defined coordinate system may have a 'model coordinate system' with 'x' and 'y' coordinates with each cell mapping to a defined latitude and longitude value pair.

The latitude and longitude are defined with respect to a grid_mapping variable, but the x and y are not, so the data variable's grid_mapping attribute should unambiguously define that the only coordinates which use the grid_mapping are latitude and longitude.

The specification defines the grid_mapping:

When the coordinate variables for a horizontal grid are not longitude and latitude, it is 
required that the true latitude and longitude coordinates be supplied via the coordinates 
attribute. If in addition it is desired to describe the mapping between the given coordinate 
variables and the true latitude and longitude coordinates, the attribute grid_mapping may be 
used to supply this description.

This indicates that a grid_mapping only relates a list of coordinate variables to the required auxiliary coordinates 'latitude' and 'longitude' if these are not coordinate variables.

Thus the grid_mapping does not provide the facility to define the CRS datum for the latitiude and longitude auxiliary coordinates in this example:

dimensions:
	time = 240 ;
	site_number = 3 ;
	bnds = 2 ;
variables:
	float air_temperature(time, site_number) ;
		air_temperature:standard_name = "air_temperature" ;
		air_temperature:long_name = "air_temperature" ;
		air_temperature:units = "K" ;
		air_temperature:ukmo__um_stash_source = "m??s03i236" ;
		air_temperature:cell_methods = "time: mean" ;
		air_temperature:grid_mapping = "latitude_longitude" ;
		air_temperature:source = "Data from Met Office Unified Model" ;
		air_temperature:coordinates = "height latitude longitude" ;
	int latitude_longitude ;
		latitude_longitude:grid_mapping_name = "latitude_longitude" ;
		latitude_longitude:semi_major_axis = 6371229. ;
		latitude_longitude:semi_minor_axis = 6371229. ;
	float time(time) ;
		time:units = "days since 0000-01-01 00:00:00" ;
		time:standard_name = "time" ;
		time:calendar = "360_day" ;
		time:axis = "T" ;
	float site_number(site_number) ;
		site_number:units = "1" ;
		site_number:long_name = "site_number" ;
	float height ;
		height:units = "m" ;
		height:standard_name = "height" ;
		height:axis = "Z" ;
	float latitude(site_number) ;
		latitude:comment = "Data points generated from bounds" ;
		latitude:bounds = "latitude_bnds" ;
		latitude:units = "degrees_north" ;
		latitude:standard_name = "latitude" ;
		latitude:axis = "Y" ;
	float latitude_bnds(site_number, bnds) ;
	float longitude(site_number) ;
		longitude:comment = "Data points generated from bounds" ;
		longitude:bounds = "longitude_bnds" ;
		longitude:units = "degrees_east" ;
		longitude:standard_name = "longitude" ;
		longitude:axis = "X" ;
	float longitude_bnds(site_number, bnds) ;

[markh]

I would like to restate the proposal in its current form:

The CF specification should change as follows.

Replace the first paragraph of 5.6 with the following text: (It is clearer to show the whole paragraph, although not all of it is changed. In the below, the new or modified text is bold:)

When the coordinate variables for a horizontal grid are not longitude and latitude, it is required that the true latitude and longitude coordinates be supplied via the coordinates attribute. If in addition it is desired to describe the mapping between the given coordinate variables and the true latitude and longitude coordinates, or to describe the figure of the Earth used to define the latitude and longitude coordinates, or another coordinate reference system definition used by some coordinates or auxiliary coordinates: a grid mapping variable is required. Such a grid mapping variable provides the description of the mapping via a collection of attached attributes. It is of arbitrary type since it contains no data. Its purpose is to act as a container for the attributes that define the mapping. The one attribute that all grid mapping variables must have is grid_mapping_name, which takes a string value that contains the mapping's name. The other attributes that define a specific mapping depend on the value of grid_mapping_name. The valid values of grid_mapping_name along with the attributes that provide specific map parameter values are described in Appendix F, Grid Mappings.

The grid mapping variables are associated with the data and coordinate variables by the grid_mapping attribute. This attribute is attached to data variables so that variables with different mappings may be present in a single file. The attribute takes a string value with two possible formats. In the first format, it is a single word, which names a grid mapping variable. In the second format, it is a blank-separated list of words "grid_mapping_variable: coordinate_variable [coordinate_variable ...] [grid_mapping_variable: ...]", which identifies one or more grid mapping variables, and with each grid mapping associates one or more coordinate_variables i.e. coordinate variables or auxiliary coordinate variables.

Using the simple form, where the grid_mapping attribute is only the name of a grid_mapping variable, 2D latitude and longitude coordinates for a projected coordinate reference system use the same geographic coordinate reference system (datum and prime meridian) as the projection is projected from.

When the coordinate variables for a horizontal grid are longitude and latitude, a grid mapping variable with grid_mapping_name of latitude_longitude may be used to specify the ellipsoid and prime meridian.

The expanded form of the grid_mapping attribute is required if one wants to store coordinate information for more than one coordinate reference system. In this case each coordinate or auxiliary coordinate is defined explicitly with respect to one and only one grid_mapping variable. This syntax may be used to explicitly link coordinates and grid mapping variables where only one coordinate reference system is used. In this case, all coordinates and auxiliary coordinates of the data variable not named in the grid_mapping attribute are unrelated to any grid_mapping variable. All coordinate names listed in the grid_mapping attribute must be coordinate variables or auxiliary coordinates of the data variable.

In order to make use of a grid mapping to directly calculate latitude and longitude values it is necessary to associate the coordinate variables with the independent variables of the mapping. This is done by assigning a standard_name to the coordinate variable. The appropriate values of the standard_name depend on the grid mapping and are given in Appendix F, Grid Mappings.

Example 5.10. British National Grid

dimensions:
  z = 100;
  y = 100000 ;
  x = 100000 ;
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 latWGS84(y, x) ;
    lat:standard_name = "latitude" ;
    lat:units = "degrees_north" ;
  double lonWGS84(y, x) ;
    lon:standard_name = "longitude" ;
    lon:units = "degrees_east" ;
  float temp(z, y, x) ;
    temp:standard_name = "air_temperature" ;
    temp:units = "K" ;
    temp:coordinates = "latWGS84 lonWGS84" ;
    temp:grid_mapping = "crsOSGB: x y crsWGS84: latWGS84 lonWGS84" ;
  float pres(z, y, x) ;
    temp:standard_name = "air_pressure" ;
    temp:units = "Pa" ;
    temp:coordinates = "latWGS84 lonWGS84" ;
    temp:grid_mapping = "crsOSGB: x y crsWGS84: latWGS84 lonWGS84" ;
  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: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 ;

(n.b. I have removed the latosgb and lonosgb coordinates from the example, as I don't think they materially add to this requirement, merely to the length of the example.)

In section 5.6 of the conformance document, replace the existing two bullets

• The type of the grid_mapping attribute is a string whose value is a single variable name.
• The specified variable name (known as a grid mapping variable) must exist in the file.

with

• The type of the grid_mapping attribute is a string whose value is of the following form, in which brackets indicate optional text:

     grid_mapping_name[: coord_var [coord_var ...]] [grid_mapping_name: [coord_var ... ]]
  

  • Note that in its simplest form the attribute comprises just a grid_mapping_name as a single word.
• Each grid_mapping_name is the name of a variable (known as a grid mapping variable), which must exist in the file.
• Each coord_var is the name of a coordinate variable or auxiliary coordinate variable, which must exist in the file and be linked to the relevant data variable.

In the remaining bullets of this section of the conformance document, replace "grid mapping variable" (singular) with "grid mapping variables" (plural).

[jonathan]

Dear Mark

Thanks for this restatement. I agree with it. I would like to make some minor (I think) editorial suggestions in this text:

• You have a very long sentence, which I think would be easier to read if it was turned round as follows: "A grid mapping variable is required if in addition it is desired to describe the mapping between the given coordinate variables and the true latitude and longitude coordinates, or to describe the figure of the Earth used to define the latitude and longitude coordinates, or to describe another coordinate reference system definition used by some coordinates or auxiliary coordinates."

• In the sentence, "Using the simple form, where the grid_mapping attribute is only the name of a grid_mapping variable, 2D latitude and longitude coordinates for a projected coordinate reference system use the same geographic coordinate reference system (datum and prime meridian) as the projection is projected from.", could we avoid using the word "datum", because (a) this is not a word which CF currently uses and (b) it is word with more than one meaning. What does it mean here, exactly? Would "ellipsoid" be a correct substitution?

• "In this case each coordinate or auxiliary coordinate is defined explicitly with respect to one and only one grid_mapping variable." I think that should say, "no more than one grid_mapping variable." As you go on to explain, it is permitted for some coord vars not to be associated with any grid mapping.

• In the final bullet of the conformance rules, I would say, "which must exist in the file. If it is an auxiliary coordinate variable, it must be listed in the coordinates attribute." That is, let's be explicit about how it is "linked".

Best wishes

Jonathan

[markh]

Replying to jonathan:

Dear Mark

Thanks for this restatement. I agree with it. I would like to make some minor (I think) editorial suggestions in this text:

• You have a very long sentence, which I think would be easier to read if it was turned round as follows: "A grid mapping variable is required if in addition it is desired to describe the mapping between the given coordinate variables and the true latitude and longitude coordinates, or to describe the figure of the Earth used to define the latitude and longitude coordinates, or to describe another coordinate reference system definition used by some coordinates or auxiliary coordinates."

that makes sense, and reads better

• In the sentence, "Using the simple form, where the grid_mapping attribute is only the name of a grid_mapping variable, 2D latitude and longitude coordinates for a projected coordinate reference system use the same geographic coordinate reference system (datum and prime meridian) as the projection is projected from.", could we avoid using the word "datum", because (a) this is not a word which CF currently uses and (b) it is word with more than one meaning. What does it mean here, exactly? Would "ellipsoid" be a correct substitution?

i think we could use ellipsoid here

• "In this case each coordinate or auxiliary coordinate is defined explicitly with respect to one and only one grid_mapping variable." I think that should say, "no more than one grid_mapping variable." As you go on to explain, it is permitted for some coord vars not to be associated with any grid mapping.

that seems fine to me

• In the final bullet of the conformance rules, I would say, "which must exist in the file. If it is an auxiliary coordinate variable, it must be listed in the coordinates attribute." That is, let's be explicit about how it is "linked".

agreed, let's be explicit

[markh]

I would like to restate the proposal in its current form:

The CF specification should change as follows.

Replace the first paragraph of 5.6 with the following text: (It is clearer to show the whole paragraph, although not all of it is changed. In the below, the new or modified text is bold:)

When the coordinate variables for a horizontal grid are not longitude and latitude, it is required that the true latitude and longitude coordinates be supplied via the coordinates attribute. A grid mapping variable is required if, in addition, it is desired to describe the mapping between the given coordinate variables and the true latitude and longitude coordinates, or to describe the figure of the Earth used to define the latitude and longitude coordinates, or to describe another coordinate reference system definition used by some coordinates or auxiliary coordinates.Such a grid mapping variable provides the description of the mapping via a collection of attached attributes. It is of arbitrary type since it contains no data. Its purpose is to act as a container for the attributes that define the mapping. The one attribute that all grid mapping variables must have is grid_mapping_name, which takes a string value that contains the mapping's name. The other attributes that define a specific mapping depend on the value of grid_mapping_name. The valid values of grid_mapping_name along with the attributes that provide specific map parameter values are described in Appendix F, Grid Mappings.

The grid mapping variables are associated with the data and coordinate variables by the grid_mapping attribute. This attribute is attached to data variables so that variables with different mappings may be present in a single file. The attribute takes a string value with two possible formats. In the first format, it is a single word, which names a grid mapping variable. In the second format, it is a blank-separated list of words "grid_mapping_variable: coordinate_variable [coordinate_variable ...] [grid_mapping_variable: ...]", which identifies one or more grid mapping variables, and with each grid mapping associates one or more coordinate_variables i.e. coordinate variables or auxiliary coordinate variables.

Using the simple form, where the grid_mapping attribute is only the name of a grid_mapping variable, 2D latitude and longitude coordinates for a projected coordinate reference system use the same geographic coordinate reference system (ellipsoid and prime meridian) as the projection is projected from.

When the coordinate variables for a horizontal grid are longitude and latitude, a grid mapping variable with grid_mapping_name of latitude_longitude may be used to specify the ellipsoid and prime meridian.

The expanded form of the grid_mapping attribute is required if one wants to store coordinate information for more than one coordinate reference system. In this case each coordinate or auxiliary coordinate is defined explicitly with respect to no more than one grid_mapping variable. This syntax may be used to explicitly link coordinates and grid mapping variables where only one coordinate reference system is used. In this case, all coordinates and auxiliary coordinates of the data variable not named in the grid_mapping attribute are unrelated to any grid_mapping variable. All coordinate names listed in the grid_mapping attribute must be coordinate variables or auxiliary coordinates of the data variable.

In order to make use of a grid mapping to directly calculate latitude and longitude values it is necessary to associate the coordinate variables with the independent variables of the mapping. This is done by assigning a standard_name to the coordinate variable. The appropriate values of the standard_name depend on the grid mapping and are given in Appendix F, Grid Mappings.

Example 5.10. British National Grid

  dimensions:
    z = 100;
    y = 100000 ;
    x = 100000 ;
  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) ;
      z:standard_name = "height_above_reference_ellipsoid" ;
      z:long_name = "height_above_osgb_newlyn_datum_masl" ;
      z: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(z, y, x) ;
      temp:standard_name = "air_temperature" ;
      temp:units = "K" ;
      temp:coordinates = "lat lon" ;
      temp:grid_mapping = "crsOSGB: x y crsWGS84: lat lon" ;
    float pres(z, y, x) ;
      temp:standard_name = "air_pressure" ;
      temp:units = "Pa" ;
      temp:coordinates = "lat lon" ;
      temp:grid_mapping = "crsOSGB: x y crsWGS84: lat lon" ;
    int crsOSGB ;
      crsOSGB:grid_mapping_name = "transverse_mercator";
      crsOSGB:semi_major_axis = 6377563.396 ;
      crsOSGB:inverse_flattening = 299.3249646 ;
      crsOSGB:longitude_of_prime_meridian = 0.0 ;
      crsOSGB:latitude_of_projection_origin = 49.0 ;
      crsOSGB:longitude_of_central_meridian = -2.0 ;
      crsOSGB:scale_factor_at_central_meridian = 0.9996012717 ;
      crsOSGB:false_easting = 400000.0 ;
      crsOSGB:false_northing = -100000.0 ;
      crsOSGB:unit = "metre" ;
    int crsWGS84 ;
      crsWGS84:grid_mapping_name = "latitude_longitude";
      crsWGS84:longitude_of_prime_meridian = 0.0 ;
      crsWGS84:semi_major_axis = 6378137.0 ;
      crsWGS84:inverse_flattening = 298.257223563 ;
  

In section 5.6 of the conformance document, replace the existing two bullets

• The type of the grid_mapping attribute is a string whose value is a single variable name.
• The specified variable name (known as a grid mapping variable) must exist in the file.

with

• The type of the grid_mapping attribute is a string whose value is of the following form, in which brackets indicate optional text:

     grid_mapping_name[: coord_var [coord_var ...]] [grid_mapping_name: [coord_var ... ]]
  

• Note that in its simplest form the attribute comprises just a grid_mapping_name as a single word.
• Each grid_mapping_name is the name of a variable (known as a grid mapping variable), which must exist in the file.
• Each coord_var is the name of a coordinate variable or auxiliary coordinate variable, which must exist in the file. If it is an auxiliary coordinate variable, it must be listed in the coordinates attribute.

In the remaining bullets of this section of the conformance document, replace "grid mapping variable" (singular) with "grid mapping variables" (plural).

[jonathan]

This looks fine to me, Mark. Thanks.

Is it OK for you, John (Caron)?

Cheers

Jonathan

[davidhassell]

I think that the content on this is looking good, the replacement text for the specification and conformance documents is clear and the example is a good illustration.

This has been discussed and improved over some months and, if John Caron is in agreement, I propose that this enhancement can be accepted with the ammendments to the specification and conformance documents as stated in Marks post on 03/15/12.

Any objections, John?

Many thanks,

David

[caron]

ok with me.

[davidhassell]

That's great, this can move to accepted. Thanks, John.

[painter1]

in implementing Ticket 70 in the CF Conventions document version 1.7, I saw that it overlaps with tickets 69, 80, and 143. In order to deal with this, I had to make some changes, to Examples 5.10 and 5.12 and associated text. My choice was to use Example 5.10 as supplied for Ticket 70, and to combine the old Examples 5.10 and 5.12 to form the new Example 5.12.

I would like to invite comments on these changes before they become final. You may see the proposed new chapter 5 at this url: ​https://github.com/cf-convention/cf-conventions/blob/781dea25a986e7d12f294257ec73e817ed544a74/ch05.adoc

[painter1]

This ticket has been implemented in the draft 1.7 version of the CF Conventions document. The ticket cannot be closed until the conformance document is also updated.