Additions and Revisions to CF Grid Mapping Attributes (v2.0)

[pbentley]

1. Title

Additions and revisions to CF grid mapping attributes to support the specification of coordinate reference system properties.

2. Moderator

Jonathan Gregory

3. Requirement

This submission is a follow-up proposal to the informative discussions that took place as part of ​CF Trac ticket #9. Consequently the requirements remain as stated in that ticket, and can be paraphrased as follows:

There is a requirement for additional CF grid mapping attributes to be defined which can be used to provide a fuller description of the characteristics of the coordinate reference system (CRS), or systems, that form the basis of spatial coordinates within a netCDF file.

Based on the discussions arising from Trac ticket #9 it was concluded that further research needs to be undertaken in order to address the complexities of vertical datums and vertical coordinate systems. Accordingly the corresponding attributes have been dropped from this revised proposal. It is hoped that a domain expert within the CF community will be able to submit a separate proposal covering these topics.

4. Initial Statement of Technical Proposal

The following sections detail the proposed changes to the CF-1.0 specification. They hopefully represent a synthesis of the discussions and conclusions arising from Trac ticket #9.

4.1. Additions and Revisions to Appendix F, Table F.1

This section describes the new and revised grid mapping attribute definitions that are required to be added to Table F.1 in Appendix F of the CF specification. Attributes are listed in alphabetical order. Attribute names appearing in normal typeface are newly defined in this proposal. Attribute names appearing in italic typeface refer to existing CF attributes for which a revised definition is proposed.

Table F.1 Grid Mapping Attributes

Attribute

Definition

crs_id

Used to specify a unique identifier for the CRS. The identifier string should be a value taken from a controlled vocabulary maintained by a recognised authority. For the crs_id attribute the recommended vocabulary is the list of CRS URN definitions [OGC-URN] maintained and published by the Open Geospatial Consortium (OGC). These URNs refer to CRS entities realised in the ​OGP/EPSG database of geodetic parameters. A list of OGC URNs corresponding to current grid mapping names appears at Table F.2. Example: “urn:ogc:def:crs:EPSG:6.3:4326”, which identifies the familiar 2D geographic CRS named “WGS 84” in the EPSG v6.3 database.

crs_name

Used to specify the well-known name of the CRS within which spatial coordinates are defined. The value of the crs_name attribute may also be taken from a controlled vocabulary such as the OGP/EPSG geodetic database referred to above. Otherwise a suitably informative, locally-defined name should be specified. Example: “OSGB 1936 / British National Grid”.

crs_wkt

Used to specify the well-known text string encoding of the CRS using the OGC WKT syntax, as defined in OGC document 06-103r3 [OGC-SFA1]. It is envisaged that this attribute typically will be written and read automatically by software agents rather than by human operators. Comparable non-CF attributes are already being used for this purpose by a number of third-party software packages (both commercial and open source). Inclusion of the crs_wkt attribute here is intended therefore to standardise this usage within the CF community.

earth_radius

Used to specify the radius, in metres, of the spherical figure used to approximate the shape of the Earth. This attribute should be specified for those projected CRS's in which the X-Y cartesian coordinates have been derived using a spherical Earth approximation. If the cartesian coordinates were derived using the ellipsoid associated with the geodetic datum then this attribute should not be defined. Example: "6371007” , which is the radius of the GRS 1980 Authalic Sphere.

ellipsoid_name

Used to specify the well-known name of the ellipsoidal figure associated with the geodetic datum and used to approximate the shape of the Earth. For coordinates based upon a spherical Earth approximation the value "Sphere" should be used. Example: “GRS 1980”.

geodetic_datum_name

Used to specify the well-known name of the geodetic datum against which geographic coordinates are referenced. For coordinates based upon a spherical Earth approximation the value "Sphere" is permissible. Example: “World Geodetic System 1984”.

inverse_flattening

Used to specify the inverse flattening (1/f) of the ellipsoidal figure associated with the geodetic datum and used to approximate the shape of the Earth. The flattening (f) of the ellipsoid is related to the semi-major and semi-minor axes by the formula f = (a-b)/a. The current attribute is used to specify the denominator of this fraction when the numerator is reduced to unity. In the case of a spherical Earth this attribute should be omitted or set to zero. Example: 298.257222101 for the GRS 1980 ellipsoid. (Note: By convention the dimensions of an ellipsoid are specified using either the semi-major and semi-minor axis lengths, or the semi-major axis length and the inverse flattening. If all three attributes are specified then the supplied values must be consistent with the aforementioned formula.)

longitude_of_prime_meridian

Specifies the longitude, with respect to Greenwich, of the prime meridian associated with the geodetic datum. The prime meridian defines the origin from which longitude values are determined. Not to be confused with the projection origin longitude (cf. longitude_of_projection_origin, a.k.a. central meridian) which defines the longitude of the map projection origin. Domain: -180.0 <= longitude_of_prime_meridian < 180.0 decimal degrees. Default = 0.0

perspective_point_height

When applicable, records the the height, in metres, of the map projection perspective point above the ellipsoid (or sphere). Used by perspective-type map projections, for example the Vertical Perspective Projection, which may be used to simulate the view from a Meteosat satellite.

projection_name

Used to specify the well-known name of the map projection operation employed to convert geographic coordinates to cartesian coordinates. It is recommended that this attribute is used to encode the familiar or vernacular name of the map projection operation in a human-readable manner so as to facilitate, for example, map labelling capabilities. Example: “UTM Zone 31N” (for which the corresponding CF grid mapping name is "transverse_mercator").

semi_major_axis

Specifies the length, in metres, of the semi-major axis of the ellipsoidal figure associated with the geodetic datum and used to approximate the shape of the Earth. Commonly denoted using the symbol “a”. In the case of a spherical Earth approximation this attribute defines the radius of the Earth. See also the inverse_flattening attribute.

semi_minor_axis

Specifies the length, in metres, of the semi-minor axis of the ellipsoidal figure associated with the geodetic datum and used to approximate the shape of the Earth. Commonly denoted using the symbol “b”. In the case of a spherical Earth approximation this attribute should be omitted (the preferred option) or else set equal to the value of the semi_major_axis attribute. See also the inverse_flattening attribute.

standard_parallel

Specifies the line, or lines, of latitude at which the developable map projection surface (plane, cone, or cylinder) touches the reference sphere or ellipsoid used to represent the Earth. Since there is zero scale distortion along a standard parallel it is also referred to as a ‘latitude of true scale’. In the situation where a conical developable surface intersects the reference ellipsoid there are two standard parallels, in which case this attribute can be used as a vector to record both latitude values, with the additional convention that the standard parallel nearest the pole (N or S) is provided first. Domain: -90.0 <= standard_parallel <= 90.0 decimal degrees.

---

4.2. Insertion of Additional Grid Mapping Examples into Appendix F

The following examples of grid mapping definitions are required to be added to Appendix F.

Example F.9. 2D Latitude-Longitude Coordinate System (Spherical Earth)

This grid mapping defines the canonical 2D geographical coordinate system based upon latitude and longitude coordinates on a spherical Earth. If required, the Earth radius can be specified via the semi_major_axis attribute.

grid_mapping_name = "lat_long_on_sphere"

dimensions:
  lat = 18 ; // dummy values
  lon = 36 ;
variables:
  double lat(lat) ;
    // conventional definition
  double lon(lon) ;
    // conventional definition
  float temp(lat, lon) ;
    temp:long_name = "temperature" ;
    temp:units = "K" ;
    temp:grid_mapping = "crs" ;
  int crs ;
    crs:grid_mapping_name = "lat_long_on_sphere" ;
    crs:crs_id = "urn:ogc:def:cs:EPSG:6.0:6422" ;   // EPSG ID 6422 == "Ellipsoidal 2D CS"
    crs:crs_name = "Spherical 2D Coordinate System" ;
    crs:ellipsoid_name = "Sphere" ;
    crs:semi_major_axis = 6371000.0 ;
    crs:inverse_flattening = 0 ;

Example F.10. 3D Latitude-Longitude-Height Coordinate System (Spherical Earth)

This grid mapping defines the canonical 3D geographical coordinate system based upon latitude and longitude and height coordinates on a spherical Earth. If required, the Earth radius can be specified via the semi_major_axis attribute.

grid_mapping_name = "lat_long_ht_on_sphere"

dimensions:
  lat = 18 ; // dummy values
  lon = 36 ;
  ht = 50 ;
variables:
  double lat(lat) ;
    // conventional definition
  double lon(lon) ;
    // conventional definition
  double ht(ht) ;
    // conventional definition
  float temp(ht, lat, lon) ;
    temp:long_name = "temperature" ;
    temp:units = "K" ;
    temp:grid_mapping = "crs" ;
  int crs ;
    crs:grid_mapping_name = "lat_long_ht_on_sphere" ;
    crs:crs_id = "urn:ogc:def:cs:EPSG:6.0:6423" ;   // EPSG ID 6423 == "Ellipsoidal 3D CS"
    crs:crs_name = "Spherical 3D Coordinate System" ;
    crs:ellipsoid_name = "Sphere" ;
    crs:semi_major_axis = 6371000.0 ;
    crs:inverse_flattening = 0 ;

Example F.11. Latitude-Longitude on the WGS 1984 Datum

This grid mapping defines the commonly-used CRS involving geodetic latitude and longitude coordinates - and potentially also ellipsoidal height - based upon the WGS 1984 geodetic datum.

grid_mapping_name = "lat_long_wgs1984" (2D case) or "lat_long_ht_wgs1984" (3D case)

dimensions:
  lat = 18 ; // dummy values
  lon = 36 ;
variables:
  double lat(lat) ;
    // conventional definition
  double lon(lon) ;
    // conventional definition
  float temp(lat, lon) ;
    temp:long_name = "temperature" ;
    temp:units = "K" ;
    temp:grid_mapping = "crs" ;
  int crs ;
    crs:grid_mapping_name = "lat_long_wgs1984" ;
    crs:crs_id = "urn:ogc:def:crs:EPSG:6.0:4326" ;   // Use EPSG ID 4979 for 3D CRS. ID 4326 refers to 2D CRS.
    crs:crs_name = "WGS 84" ;
    crs:geodetic_datum_name = "World Geodetic System 1984" ;
    crs:longitude_of_prime_meridian = 0.0 ;
    crs:ellipsoid_name = "WGS 84" ;
    crs:semi_major_axis = 6378137.0 ;
    crs:inverse_flattening = 298.257223563 ;

Example F.12. British National Grid (with CRS_WKT attribute)

This example illustrates the use of grid mapping attributes to provide a full description of the 2D projected CRS that forms the basis of the British National Grid reference system. It also demonstrates how the same information could be encoded - possibly in an automated fashion by software applications - in OGC WKT format using the crs_wkt attribute.

grid_mapping_name = "british_national_grid"

dimensions:
  lat = 648 ; // dummy values
  lon = 648 ;
  y = 18 ;
  x = 36 ;
variables:
  double x(x) ;
    x:standard_name = "projection_x_coordinate" ;
    x:long_name = "x coordinate of projection" ;
    x:units = "m" ;
  double y(y) ;
    y:standard_name = "projection_y_coordinate" ;
    y:long_name = "y coordinate of projection" ;
    y:units = "m" ;
  double lat(y, x) ;
    // conventional definition
  double lon(y, x) ;
    // conventional definition
  float temp(y, x) ;
    temp:long_name = "temperature" ;
    temp:units = "K" ;
    temp:coordinates = "lat lon" ;
    temp:grid_mapping = "crs" ;
  int crs ;
    crs:grid_mapping_name = "british_national_grid" ;
    crs:crs_id = "urn:ogc:def:crs:EPSG:6.0:27700" ;
    crs:crs_name = "OSGB 1936 / British National Grid" ;
    crs:geodetic_datum_name = "OSGB 1936" ;
    crs:longitude_of_prime_meridian = 0.0 ;
    crs:ellipsoid_name = "Airy 1830" ;
    crs:semi_major_axis = 6377563.396 ;
    crs:semi_minor_axis = 6356256.910 ;
    crs:inverse_flattening = 299.3249646 ;
    crs:projection_name = "British National Grid" ;
    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:crs_wkt = "[PROJCS ['OSGB 1936 / British National Grid',
      GEOGCS ['OSGB 1936',
        DATUM ['OSGB 1936', SPHEROID ['Airy 1830', 6377563.396, 299.3249646]],
        PRIMEM ['Greenwich', 0], UNIT ['Degree', 0.0174532925199433]],
      PROJECTION ['Transverse Mercator'],
      PARAMETER ['False Easting', 400000], PARAMETER ['False Northing', -100000],
      PARAMETER ['Central Meridian', -2.0], PARAMETER ['Scale Factor', 0.9996012717],
      PARAMETER ['Latitude of Origin', 49.0],
      UNIT ['Meter', 1.0]]" ;

In this example the optional crs_wkt attribute is shown spread across multiple lines. In a netCDF file such an attribute value would, of course, appear as a single text string. Also, occurrences of the single-quote character would be replaced with double-quote characters.

Example F.13. Cartesian (X-Y) Coordinates based on the Vertical Perspective Projection

The following example demonstrates the use of grid mapping attributes to describe X-Y cartesian coordinates based on the vertical perspective projection. Such a CRS might be used, for example, to describe image data that simulates the view from a Meteosat satellite.

grid_mapping_name = "vertical_perspective"

variables:
  double x(x) ;
    // conventional definition
  double y(y) ;
    // conventional definition
  double lat(y, x) ;
    // conventional definition
  double lon(y, x) ;
    // conventional definition
  float temp(lat, lon) ;
    temp:long_name = "temperature" ;
    temp:units = "K" ;
    temp:grid_mapping = "crs" ;
  int crs ;
    crs:grid_mapping_name = "vertical_perspective" ;
    crs:crs_name = "X-Y Coordinates based on Vertical Perspective Projection" ;   // Fabricated for this example.
    crs:geodetic_datum_name = "World Geodetic System 1984" ;
    crs:longitude_of_prime_meridian = 0.0 ;
    crs:ellipsoid_name = "WGS 84" ;
    crs:semi_major_axis = 6378137.0 ;
    crs:inverse_flattening = 298.257223563 ;
    crs:projection_name = "Vertical Perspective" ;
    crs:latitude_of_projection_origin = 0.0 ;   // Above the equator...
    crs:longitude_of_projection_origin = 75.0 ; // ... and over the Indian Ocean.
    crs:perspective_point_height = 36000000 ;   // 36,000 km
    crs:earth_radius = 6371007 ;   // Indicates that the projection used a spherical Earth approximation.

The crs_id attribute is omitted from the above definition as, currently, a unique identifier for this map projection has yet to be assigned in the EPSG/OGP geodetic database.

---

4.3. Addition of New Sub-Section F.1 to Appendix F

The following sub-section is required to be added to Appendix F. This sub-section is also required to be repeated (or paraphrased) as a new section entitled F. Grid Mapping Attributes appended to the ​CF conformance document.

F.1. Recommended minimum set of grid mapping attributes

In order to achieve a basic level of consistency of specification it is proposed that, wherever practicable, a minimum set of attribute values is employed to specify the CRS referenced by a netCDF variable. The recommended minimum set of grid mapping attributes for describing 2D geographic and 2D projected coordinate reference systems is given below.

F.1.1. Recommended minimum set of attributes required to describe a 2D geographic CRS:

grid_mapping_name
crs_id*
crs_name
geodetic_datum_name
ellipsoid_name
semi_major_axis
semi_minor_axis and/or inverse_flattening
longitude_of_prime_meridian

(* if known)

In the case of a 3D geographic CRS the third dimension (or axis) is height above or below the ellipsoid, in which case a further parameter – units of ellipsoidal height – is normally required. However, this parameter typically will be defined via the units attribute for the relevant coordinate variable (e.g. Z). Hence no separate attribute is defined here.

F.1.2. Recommended minimum set of attributes required to describe a 2D projected CRS:

grid_mapping_name
crs_id*
crs_name
geodetic_datum_name
ellipsoid_name
semi_major_axis
semi_minor_axis and/or inverse_flattening
longitude_of_prime_meridian
projection_name
latitude_of_projection_origin
longitude_of_projection_origin
earth_radius#

(* if known)
(# if the map projection is based on a spherical figure of Earth)

Additional projection-specific attributes should be defined as required, e.g. false_easting, false_northing, scale_factor_at_projection_origin, and so on.

---

4.4. Addition of New Sub-Section F.2 to Appendix F

The following sub-section is required to be added to Appendix F.

F.2 OGC CRS Identifiers corresponding to CF grid mapping definitions

Table F.2 lists the Open Geospatial Consortium (OGC) URNs for the coordinate reference systems, coordinate systems, and map projections (OGC 'coordinate operation methods') that correspond to the example grid mapping names illustrated in this version of the CF specification. Grid mapping names that are not currently associated with an equivalent OGC URN (e.g. "rotated_latitude_longitude") do not appear in Table F.2. It is noted that the majority of grid mapping names defined in CF-1.0 refer to OGC coordinate operation methods (i.e. map projections) rather than coordinate reference systems.

The values defined in the OGC URN Identifier column may be used, as and when appropriate, to define the crs_id grid mapping attribute. The OGC URN syntax is described in reference [OGC-URN].

Table F.2. OGC URNs corresponding to CF grid mapping names

CF Grid Mapping Name	OGC URN Identifier	OGC Object Type*
albers_conical_equal_area	urn:ogc:def:method:EPSG:6.0:9822	Coordinate Operation Method
azimuthal_equidistant	urn:ogc:def:method:EPSG:6.0:9822	Coordinate Operation Method
azimuthal_equalarea	urn:ogc:def:method:EPSG:6.0:9820	Coordinate Operation Method
british_national_grid	urn:ogc:def:crs:EPSG:6.0:27700	2D Coordinate Reference System
lambert_conformal_conic (1SP)	urn:ogc:def:method:EPSG:6.0:9801	Coordinate Operation Method
lambert_conformal_conic (2SP)	urn:ogc:def:method:EPSG:6.0:9802	Coordinate Operation Method
lat_long_on_sphere	urn:ogc:def:cs:EPSG:6.0:6422	2D Coordinate System
lat_long_ht_on_sphere	urn:ogc:def:cs:EPSG:6.0:6423	3D Coordinate System
lat_long_wgs1984	urn:ogc:def:crs:EPSG:6.0:4326	2D Coordinate Reference System
lat_long_ht_wgs1984	urn:ogc:def:crs:EPSG:6.0:4979	3D Coordinate Reference System
polar_stereographic	urn:ogc:def:method:EPSG:6.0:9810	Coordinate Operation Method
stereographic	urn:ogc:def:method:EPSG:6.0:9809	Coordinate Operation Method
transverse_mercator	urn:ogc:def:method:EPSG:6.0:9807	Coordinate Operation Method

(* OGC object types can be considered equivalent to like-named objects in the OGP/EPSG database.)

---

4.5. Addition of References to Bibliography

The following bibliographic references are required to be appended to the CF bibliography chapter.

[OGC-SRC] Topic 2: Spatial Referencing by Coordinates. OGC Abstract Specification. OGC document 04- 046r3. 16 August 2004. (URL: ​http://www.opengeospatial.org/standards/as)

[OGC-SFA1] OpenGIS Implementation Specification for Geographic information - Simple feature access - Part 1: Common architecture. OGC document 06-103r3. 5 October 2006. (URL: ​http://www.opengeospatial.org/standards/sfa)

[OGC-URN] Definition Identifier URNs in OGC Namespace. OGC Best Practices Paper. OGC document 06- 023r1. 8 August 2007. (URL: ​http://www.opengeospatial.org/standards/bp)

---

5. Benefits

As per ​original Trac ticket #9.

6. Status Quo

As per ​original Trac ticket #9.

[pbentley]

Erratum:

The definition of the variable temp in Example F.13 should mirror that of the same variable in Example F.12.

--Phil

[jonathan]

Dear Phil

Thank you for your hard work on your detailed revised proposal. I'm generally happy with this version, but I have some more comments (my own views - not as moderator!).

1. Your proposal changes the meaning of the grid_mapping_name attribute. Up to now, it has been the name of one of the permitted mappings of Appendix F. That is, it identifies the operation and the required parameters (not the values of those parameters) which relate coordinate space to geographical location. Knowing the operation and the parameters, generic software could do the transformation. In your proposal, there are values of grid_mapping_name such as british_national_grid. That's a different kind of thing; it implies a particular projection (transverse Mercator) and choice of parameters. If we make this change, the projection is no longer identified (as in your example F.12) and generic software would not be able to carry out the transformation. I don't think we should make this change. I think that we should retain the current function of grid_mapping_name, which would be transverse_mercator in this case. Knowing this, and the parameters for the projection, generic software can transform to and from the British National Grid. In addition, the projection is identified as the British National Grid by the crs_id and crs_name, and that further information may be helpful to particular software, as was agreed in the previous ticket. Hence I think examples F.11 and F.12 can certainly be included as examples of latitude_longitude (see also below) and transverse_mercator, but not as new values of grid_mapping_name. I would also amend your section F.2. I think the first column in the table should be changed: some of those are possible values of grid_mapping_name, but not all of them.

2. The coordinate reference systems are the essential contents for table F.2. They are the ones which combine a method with particular parameters. Do you (or others) think it is important to be able to give a crs_id for the pure projection (coordinate operation) methods? If it is useful, I wouldn't object, but I wonder why it is useful.

3. Table F.2 is needed because the OGP/EPSG database isn't easily accessible. Shouldn't this table contain the values of parameters which define coordinate reference systems? If it does, the CF checker can verify them. (The table would be needed in some machineable form e.g. XML.) Otherwise, there can be no check that the crs_id and the explicit parameters are consistent. If they could be inconsistent, what should an application believe?

4. We should add a type column to the list of attributes in appendix F (string or numeric, like Appendix A).

5. We had some discussion in the previous ticket about the crs_wkt attribute. Personally, I am still unhappy about it, for two reasons. First, it is a departure for CF and inconsistent with one of principles to include an attribute that is not easily readable by humans. This attribute is provided for the benefit of software, but in earlier discussions it was argued that it was less convenient for software to parse a long attribute into components than to have the components stored in separate attributes. That is why we invented the grid_mapping variable with its separate attributes. Has this argument changed? Why can't these other packages read our separate attributes? Second, the crs_wkt attribute could be inconsistent with the crs_id and the explicit parameter attributes. The CF checker could check this, but you can't guarantee consistency if you introduce redundancy.

6. I don't understand the sentence "The current attribute ..." in the definition of inverse_flattening.

7. I would suggest the name latitude_longitude instead of lat_long_on_sphere because (a) we generally avoid abbreviations in our controlled vocabulary (b) to add on_sphere confuses the roles of projection and geodetic datum. A grid_mapping_name of latitude_longitude is useful as an identity operation for the coordinates; the coordinates are identical with the geographical location (unlike in transverse Mercator, rotated pole, etc.). The parameters of the ellipsoid are provided as additional information.

8. I don't think we should include latitude-longitude-height on sphere (Example F.10). Appendix F is about horizontal coordinate systems and we don't anywhere else combine these with vertical coordinates. Let's think about this if someone has such a requirement.

9. I don't agree with Section F.1. I think grid_mapping_name is mandatory and the rest are optional. I don't think one can recommend including the parameters describing the geodetic datum and the ellipsoid, because such information is not likely to be supplied in GCM data, where it's not needed, and hence GCM data would always produce unhelpful warnings in the CF-checker in future.

10. Before the CF standard document was moved to the PCMDI site, the various projections were given as unnumbered subsections of Appendix F. Now they are given as examples (I had noticed this before you made your proposal). I think that we should change them back, because they are not really examples.

Best wishes

Jonathan

[pbentley]

Replying to jonathan:

Hi Jonathan,

1. Your proposal changes the meaning of the grid_mapping_name attribute. [...] Hence I think examples F.11 and F.12 can certainly be included as examples of latitude_longitude (see also below) and transverse_mercator, but not as new values of grid_mapping_name.

Yes, the British National Grid example was included as just that, an example. I have no problem with the grid_mapping_name attribute being set to 'transverse_mercator', as you suggest, and the corresponding entry removed from Table F.2. However...

2. The coordinate reference systems are the essential contents for table F.2. They are the ones which combine a method with particular parameters. Do you (or others) think it is important to be able to give a crs_id for the pure projection (coordinate operation) methods?

... I suspect that I may have misinterpreted the conclusions arising from the original proposal, which seemed to suggest that it would be useful to specify the OGC URN corresponding to each CF grid mapping name. On reflection, the fact that CF grid mappings are used to identify a mixture of different coordinate system concepts means that Table F.2 cannot sensibly be used to identify the OGC URNs for grid mappings that are not 2D or 3D CRS's. As you intimate, there is little value encoding a URN for, say, a map projection method in the 'crs_id' attribute (indeed such usage would be erroneous).

Accordingly, Table F.2 should, I believe, either be limited to listing just the OGC URNs corresponding to CF grid mapping names that represent genuine 2D/3D CRS's, or else be dropped from the proposal altogether. I prefer the latter option. So...

3. Table F.2 is needed because the OGP/EPSG database isn't easily accessible. Shouldn't this table contain the values of parameters which define coordinate reference systems? If it does, the CF checker can verify them. (The table would be needed in some machineable form e.g. XML.) Otherwise, there can be no check that the crs_id and the explicit parameters are consistent. If they could be inconsistent, what should an application believe?

... I'm not convinced (yet) that it is desirable or indeed practicable to duplicate parts of the OGP/EPSG geodetic database as part of the CF conventions document or its supporting infrastructure. The EPSG database can now readily be queried (by humans, not machines yet) through their new-ish online web form (​http://www.epsg-registry.org/).

4. We should add a type column to the list of attributes in appendix F (string or numeric, like Appendix A).

Yes, that would be useful. Presumably this is something that the CF specification editor could do 'offline' with my input.

5. We had some discussion in the previous ticket about the crs_wkt attribute. Personally, I am still unhappy about it, for two reasons. [...]

My interpretation of the comments on the original proposal was that this attribute would be beneficial. We'll have to see how the votes fall :-)

6. I don't understand the sentence "The current attribute ..." in the definition of inverse_flattening.

A good example of obfuscation, I'd say! The offending sentence can be removed.

7. I would suggest the name latitude_longitude instead of lat_long_on_sphere

No objection.

8. I don't think we should include latitude-longitude-height on sphere

No objection.

9. I don't agree with Section F.1. I think grid_mapping_name is mandatory and the rest are optional. I don't think one can recommend including the parameters describing the geodetic datum and the ellipsoid, because such information is not likely to be supplied in GCM data [...]

Agreed re grid_mapping_name being mandatory. The recommendations come with the caveat "wherever practicable" in the introductory paragraph so I think the intent is clear.

10. Before the CF standard document was moved to the PCMDI site, the various projections were given as unnumbered subsections of Appendix F. Now they are given as examples (I had noticed this before you made your proposal). I think that we should change them back, because they are not really examples.

IMHO that is an editorial decision :)

Regards,

--Phil

[edavis]

Hi Phil, Jonathan, all,

Replying to pbentley:

Replying to jonathan:

I wrote a few comments before seeing your latest comments Phil. So, there may be some redundancy.

I agree with your concern about duplicating the EPSG tables in the CF spec. Especially since, as you will see below, I think we should provide separate *_id attributes for many of the other non-CRS EPSG codes.

Anyway, below are my comments written in response to Jonathan's comment.

Ethan

---

1) I think we need to add some text to the 5.6 "Grid Mappings and Projections" section of the CF spec to differentiate between describing the CRS for a set of coordinates and describing a transformation between two sets of coordinates. The current grid mapping spec provides a way to describe a transformation between a set of coordinate axes (x(x) and y(y) e.g.) and a set of auxiliary coordinates (lat(y,x) and lon(y,x) e.g.). This proposal improves on our ability to describe those transformations. It also allows us to describe the CRS for a single set of coordinates. I think we need to add some text that points out this difference and describes how the set of coordinates are linked to a CRS. The current grid mapping spec uses coordinate variables AND the coordinates attribute to link two sets of coordinates to the grid mapping variable. For a CRS to a single set of coordinates, I would think we should allow the connection to be coordinate variables OR the coordinates attribute. [In EPSG lingo, I think the current grid mapping variable describes a "Coordinate Operation" (CO) and the grid_mapping_name attribute specifies the "Coordinate Operation Method" used in the coordinate operation.]

2) There are a number of *_name attributes that are defined as "well known names" and only one *_id attribute that uses EPSG codes. The EPSG codes seem much more well defined and stable than any "well known names" we might find or develop. Also, there are EPSG codes for all the building blocks needed to construct a CRS or coordinate operation (ellipse, datum, projection, cs, crs, units, etc). So, I would suggest we add a few more *_id attributes that will allow us to piece together CRS and CO using EPSG codes. I think this would mean for each new *_id attribute we need another table listing the EPSG codes (and/or OGC URNs). It would also mean that the *_name could just be human readable labels rather than identifiers.

3) Then again, I'm a bit wary of what I just said above. I'm not sure I like the idea of *_id attributes or "well known names" in this situation. Maintaining a controlled vocabulary for sets of parameters (e.g., a fully defined CRS) seems quite different from our past controlled vocabulary efforts. Standard names, grid mapping names, and dimensionless vertical coordinate formulas are all identifiers linked with definitions; any parameters are given in attributes not given in the definition. I know there has been debate on this. I just worry this is starting on a slippery slope away from self-describing.

4) And of course there are redundancy, inconsistency, and incompatibility issues if we allow both externally defined parameters (*_id) as well as internally specified parameters. Again something that has already been discussed.

Anyway, I have some more details written down for possible additions and changes to this proposal dealing with some of the above points. But typing those up will have to wait till next week or next year.

Happy holidays everyone.

Ethan

[edavis]

Hi again,

One more quick comment. If we don't have tables of CF "certified" EPSG codes and/or OGC URNs, I think we need to be more explicit about what kinds of OGC URNs are allowed. The OGC URN spec allows for compound URNs and parameterized URNs which quickly get very unwieldy (they play the same role but are much harder to read than WKT). I think, if we don't include these tables, we should restrict any OGC URNs to "single object" URNs.

Ethan

[pbentley]

Replying to edavis:

Hi Ethan

2) There are a number of *_name attributes that are defined as "well known names" and only one *_id attribute that uses EPSG codes. The EPSG codes seem much more well defined and stable than any "well known names" we might find or develop. Also, there are EPSG codes for all the building blocks needed to construct a CRS or coordinate operation (ellipse, datum, projection, cs, crs, units, etc). So, I would suggest we add a few more *_id attributes that will allow us to piece together CRS and CO using EPSG codes. I think this would mean for each new *_id attribute we need another table listing the EPSG codes (and/or OGC URNs). It would also mean that the *_name could just be human readable labels rather than identifiers.

In principle I agree, and my original proposal included many of the additional *_id attributes that you refer to. However, there seemed to be some resistance to incorporating these, partly, I think, because of the CF 'rule' about not introducing changes before there is a firm need for them. Hence they were dropped from the revised proposal.

IMHO, it may be preferable to tackle such attributes via a subsequent proposal. My concern is that, in trying to resurrect them here, we will get into a circular debate about the pros and cons of using id attributes. And potentially miss the opportunity to adopt some of the less contentious features of the current proposal. It's been a long, long road already...!

3) Then again, I'm a bit wary of what I just said above. I'm not sure I like the idea of *_id attributes or "well known names" in this situation. Maintaining a controlled vocabulary for sets of parameters (e.g., a fully defined CRS) seems quite different from our past controlled vocabulary efforts. Standard names, grid mapping names, and dimensionless vertical coordinate formulas are all identifiers linked with definitions; any parameters are given in attributes not given in the definition. I know there has been debate on this. I just worry this is starting on a slippery slope away from self-describing.

Ultimately I think there will be some pieces of 'well-known' metadata that we just won't want to ship around in every netcdf file simply to adhere to the self-describing ideal. Many CRS properties are likely to fall into that category, I believe. For example, we don't consider it desirable (or practicable) to include the mathematical formula for the lat/lon to polar stereographic X/Y conversion in relevant netcdf files. It's accepted that this is a hint: software has to go look up the conversion algorithm somewhere else, e.g. a projection library.

When standard names/concepts evolve to include other properties (authority, revision history, proposer, ...) then presumably that ancillary information will need to be looked up externally too.

--Phil

[jonathan]

Dear all

Thank you, Phil and Ethan, for your contributions. It looks like there are not many serious outstanding issues at this point, so we are quite near consensus. According to the rules, the proposal would need support from another member of the CF conventions committee in order to be accepted. Also I think there are a couple of questions on which views from more people would be helpful:

1. The proposal allows an OGC/EPSG id to be given for a coordinate reference system. The id implies the ellipsoid and map projection, which would also be stored in separate attributes of the grid_mapping variable, according to the proposal. Applications which understand map projections can make use of these separate attributes; this is backward-compatible with the existing CF standard. The CRS id is thought useful (discussion in previous ticket) for those applications that are able to recognise it and make use of other properties of the CRS known to them as a result. But it is possible that the attributes explicitly defining the coordinate reference system and the CRS id attribute could be inconsistent. The EPSG database exists online, Phil explains, but is not machine-readable. Hence there is no way of automatically checking for possible inconsistencies. The only way the CF checker could do it would be if we copied relevant parts of the EPSG database into the CF standard in a machine-readable way. Should we do this? Is potential inconsistency a problem? If the attributes and the CRS id are inconsistent, which is correct? For example, if two variables are compared, should the application conclude they are on the same CRS if their CRS id's are the same, or if the attributes detailing the CRS are the same?

2. The proposal introduces a crs_wkt attribute of the data variable, which is a concatenation of the separate attributes of the grid_mapping variable describing the CRS. The format of this attribute is an OGC standard and is used in netCDF files by some existing software, so is included in the proposal to standardise that practice. This attribute requires parsing, which is a bit more awkward than the grid_mapping attributes, which were introduced precisely to avoid the need to parse a long string into bits and convert the bits into other data types. This attribute is obviously redundant, since it repeats information which is elsewhere in the file, and it is not easily human-readable. On both grounds it is a departure from normal CF practice. The CF-checker could detect inconsistency, but that doesn't guarantee there is no inconsistency. If there is inconsistency between the crs_wkt attribute and the grid_mapping variable, which is correct? Is the crs_wkt a good idea?

Thanks for any input.

Jonathan

[pbentley]

Replying to jonathan:

Hi Jonathan

Thanks for summarising the current status of this ticket.

1. The proposal allows an OGC/EPSG id to be given for a coordinate reference system. The id implies the ellipsoid and map projection, which would also be stored in separate attributes of the grid_mapping variable, according to the proposal. [snip] But it is possible that the attributes explicitly defining the coordinate reference system and the CRS id attribute could be inconsistent...

Hence there is no way of automatically checking for possible inconsistencies. The only way the CF checker could do it would be if we copied relevant parts of the EPSG database into the CF standard in a machine-readable way. Should we do this?

I believe not. At present I do not see a need to do this. Also, in view of the pace of change to the CF specification I'm not convinced that we have the resources to achieve this even if it was desirable. If netCDF-aware software applications (including the CF checker) need to 'understand' OGP/EPSG entities then it is a fairly straightforward task to build relational tables of those entities using the standard SQL scripts supplied by OGP/ESPG. (NB: I built the tables in a MySQL environment in about 1 hour.)

Is potential inconsistency a problem? If the attributes and the CRS id are inconsistent, which is correct? For example, if two variables are compared, should the application conclude they are on the same CRS if their CRS id's are the same, or if the attributes detailing the CRS are the same?

Potentially, yes. But as with other metadata, there is an onus on data producers to ensure that CRS definitions are correct and internally consistent. My view on this is that directly-specified properties (values defined explicitly within the netCDF file) should take precedence over indirectly-specified properties whose values are determined by dereferencing a pointer such as is provided, for example, by the crs_id attribute.

2. The proposal introduces a crs_wkt attribute of the data variable, which is a concatenation of the separate attributes of the grid_mapping variable describing the CRS. The format of this attribute is an OGC standard and is used in netCDF files by some existing software, so is included in the proposal to standardise that practice... Is the crs_wkt a good idea?

As per my previous responses to this ticket, I believe that it would be beneficial to standardise the name and usage of this attribute now rather than have various software vendors or developers independently devise a number of alternative, potentially conflicting, attributes doing much the same thing.

Regards,

--Phil

[edavis]

Hi all,

I have mixed feelings about adding a crs_wkt attribute to contain a OGC WKT formatted string. Three concerns on this (the first two have already been discussed):

1) Having two ways to encode the same information is bound to lead to interoperability issues.

2) Redundancy also leads to the possibility of inconsistent information which compounds the interoperability issues.

3) I don't think WKT really gets us much in terms of functionality and actually falls short in some ways. For instance, WKT does not deal with temporal coordinates or dimensionless vertical coordinates.

So, I wonder if it wouldn't be worth splitting off the inclusion of WKT in CF as a separate issue. That would allow some other important additions to be made without being hung up by discussion on the WKT issue.

Similarly, I wonder if we should split off the issue of crs_id and the *_name attributes as the discussion of allowed values and when to use them seems like it needs more discussion.

My motivation for these suggestions is that I would like to quickly get the horizontal datum information (ellipsoid shape and prime meridian) into the grid mapping section of the CF specification. I'm working on producing CRS from netCDF files to use in our WCS server and this is the main piece of information that can't be included in a standard way. Also, I suspect the horizontal datum parts of Phil's proposal aren't very contentious.

Phil, Jonathan, any objection to my writing up three new issues/proposals to possibly replace this proposal?

Ethan

[jonathan]

It would be good if we could conclude this discussion with agreement to adopt some form of this proposal. Let's see what we can agree on this ticket before we start other tickets.

There has been no discussion following my summary of 27 Jan except about the crs_wkt and crs_id/crs_name issues. In the present ticket only Phil, Ethan and I have contributed, but there was other support expressed for the previous version of the proposal in ticket 9, including from John Caron and Rich Signell, who are members of the conventions committee. In that ticket also, the only significant disagreements were related to the same two issues. Hence I conclude that we have accepted the proposal, according to the rules, apart from those two issues. Thanks to all who contributed.

On the outstanding issues, further comments would be welcome. Please see the last three entries in this ticket. I will leave this ticket open for further discussion about them. Maybe we can include them in the same update to the conventions document.

Jonathan

[pbentley]

Replying to jonathan:

Hi Jonathan,

Many thanks for moderating this proposal. I would concur with your conclusions. Having come this far it would seem to make sense to at least adopt those elements of the proposal for which there is broad endorsement. Hopefully some of the other features can be pursued as part of follow-up proposals, as per Ethan's suggestion.

--Phil

[rsignell]

Replying to jonathan:

There has been no discussion following my summary of 27 Jan except about the crs_wkt and crs_id/crs_name issues.

Going back and looking at the history of this crs_id and crs_wkt discussion, it seems that there were two schools of thought: Rob Lowry, Phil & I were supporting these tags because software exists that could use these specifications immediately to do useful projection and datum transformations. Others including Jonathan were generally against the idea, on grounds of duplication and concerns with how to resolve conflicts if these tags don't agree with the standard grid_mapping attributes.

I must say after thinking about this some more, I'm now more in favor of not using the crs_id, and crs_wkt. As long as we specify the datum and projection information unambiguously and completely, we should leave it at that, and then make it a priority to write the software that maps the CF convention into other namespaces, such as the EPSG IDs or the OGC WKT. It seems that this mapping from one set of conventions to another should take part outside of the CF conventions.

I spoke to Benno Blumenthal about this, who knows a lot more about this stuff, and he said he would go back and read the ticket 9 and 18 info, and then weigh in on the issue also (I found he has not been getting these messages when Trac tickets change).

-Rich

[rsignell]

Going back and looking at the history of this crs_id and crs_wkt discussion, it seems that there were two schools of thought: Rob Lowry, Phil & I...

I meant Roy Lowry, of course. Grrr....

-Rich

[benno]

My suggestions are based on an evolution of how metadata is encoded in netcdf files: rather than simply allowing multiple conventions in netcdf files by a comma-separated list in the Conventions attribute, specify prefixes so that attributes can be explicitly labelled as belonging to a different convention. In particular, were I to want to use attributes from the convention used by WCS to describe projections, I would use a conventions tag in the file like,

Conventions = "CF-1.0, wcs=​http://www.opengis.net/wcs/1.1/"

means the default convention is CF-1.0 (i.e the usual usage), but any attribute starting 'wcs:' belongs to the convention defined by the namespace ​http://www.opengis.net/wcs/1.1/ (which is how wcs or any other XML convention standardizes its labels). This whould change the WGS 84 example, slightly, to

dimensions:
  lat = 18 ; // dummy values
  lon = 36 ;
variables:
  double lat(lat) ;
    // conventional definition
  double lon(lon) ;
    // conventional definition
  float temp(lat, lon) ;
    temp:long_name = "temperature" ;
    temp:units = "K" ;
    temp:grid_mapping = "crs" ;
    temp:wcs\:gridCRS = "crs" ;
  int crs ;
    crs:grid_mapping_name = "lat_long_wgs1984" ;
    crs:wcs\:GridBaseCRS = "urn:ogc:def:crs:EPSG:6.0:4326" ;   // Use EPSG ID 4979 for 3D CRS. ID 4326 refers to 2D CRS.
    crs:crs_name = "WGS 84" ;
    crs:geodetic_datum_name = "World Geodetic System 1984" ;
    crs:longitude_of_prime_meridian = 0.0 ;
    crs:ellipsoid_name = "WGS 84" ;
    crs:semi_major_axis = 6378137.0 ;
    crs:inverse_flattening = 298.257223563 ;
Conventions = "CF-1.0, wcs=http://www.opengis.net/wcs/1.1/"

where gridCRS and GridBasCRS are the tags used in WCS to characterize projects.

This keeps the redundancy out of CF, but allows alternate specifications to be put in a netcdf file. It also makes use of standards that other people maintain.

There are a number of reasons for doing it this way, listing of which would probably hide the essence of the proposal and should be put elsewhere. The short version is redundant representations belong to different conventions, and there is then a framework for writing down the mappings between the different conventions, and for tagging datasets with them. This would allow creation of a system that could deliver the metadata in alternate representations, so that WCS applications could use WCS-style information, and CF applications could use CF information, regardless of the actual source of the data being analyzed.

Note that recent and near-term changes to netcdf make this possible -- we could not have made this choice two years ago.

[caron]

The usual apologies for taking so long with this.

Ethan and I have been talking this over at some length. We think that splitting up the proposal would be in line with CF's process of making incremental progress on the things that we are in (almost) consensus on.

We would propose the following incremental steps:

1) Define the attributes that describe the horizontal datum (ellipse/sphere and prime meridian) along with reasonable defaults when not specified. That will allow mapping CF to GIS/OGC. This would be a great first step.

2) Review the current grid mappings for completeness, propose new ones (Phil suggests vertical perspective, CDM needs that plus Mercator, Orthographic).

3) Specifying a vertical datum is more complex, and may take more time to get right.

Ethan has volunteered to split Phil's proposal, and at least get 1) written up. I think that should proceed unless Phil wants to do it.

[edavis]

Hi all,

Replying to caron:

Ethan has volunteered to split Phil's proposal, and at least get 1) written up. I think that should proceed unless Phil wants to do it.

I added a GridMappingAndCrs page to the wiki with links to two draft proposal wiki pages, both are mostly pulled from this proposal:

• GridMapHorizDatum - proposes adding new grid mapping attributes to describe the horizontal datum used by a grid mapping. One addition I made was to try to state something about default values for the ellipsoid. However, I didn't state it very strongly and I'm not really sure what values would be reasonable defaults.
• GridMapNames - proposes adding new grid mappings to the existing 8 grid mapping types. I only added two: Vertical Perspective and Mercator. If you have any you would like to add, let me know or add them on the wiki.

I will add these two proposals as new tickets after some time for comments/additions. [Seems like it might be handy for editing to reference versions of the wiki page in the tickets. Or is the preference to include the actual proposal text in the ticket?]

Also, on the GridMappingAndCrs page, I also list some possible future proposals that I think cover most of the content in Phil's proposal.

Thanks,

Ethan

[jonathan]

Dear all

Three weeks ago I concluded that we had accepted Phil's proposal, subject to various small changes (mostly ones which he and I agreed in this ticket), with the exception of the crs_id and crs_wkt attributes. The subsequent additions from Phil, Rich, John and Ethan support this conclusion. Benno has made a somewhat different proposal about how to include crs_id, which touches on the wider and recurring issue of how to incorporate other standards in CF without repeating them. That proposal would require a large new discussion, so I would suggest that Benno raise it in a new ticket.

I append the changes we have thus agreed in this ticket. I have omitted geodetic_datum_name (geodetic datum = ellipsoid + geoid) and projection_name. They could be reproposed. I have included the vertical perspective projection, with the aid of text from Ethan in his GridMapNames wiki, since Phil argued for it in the earlier ticket, and it has been supported by Ethan and John. Ethan and John would also like to add some other projections, but they can be the subject of new tickets.

Regarding the process for changes to the conventions, I think that the trac tickets should be used, including the detailed text. Wikis are not emailed out, so do not bring themselves to people's attention, and are not clearly related to tickets. However, that's a discussion for the email list, I think!

I'm going to close this ticket now, requesting Velimir to make the following changes, in the standard document (marked as provisional) and the conformance document, and increment the version number, following the rules. Phil should be added to the list of Additional Authors.

Thanks to Phil for working on the proposal and to everyone for their contributions to the discussion.

Jonathan

Addition to preamble of Appendix F, Grid Mappings

Append to the first paragraph: "The attributes which describe the ellipsoid may be included as applicable with any grid mapping."

Additions to Appendix F, Table F.1, Grid Mapping Attributes

Attribute

Definition

crs_name

Used to specify the name of the coordinate reference system (the combination of ellipsoid and projection) within which spatial coordinates are defined. The value of the crs_name attribute is not standardised by this convention, but it may be taken from a controlled vocabulary such as the OGP/EPSG database of geodetic parameters [OGP/EPSG]. Otherwise a suitably informative name should be specified. Example: "OSGB 1936 / British National Grid".

earth_radius

Used to specify the radius, in metres, of the spherical figure used to approximate the shape of the Earth. This attribute should be specified for those projected coordinate reference systems in which the X-Y cartesian coordinates have been derived using a spherical Earth approximation. If the cartesian coordinates were derived using an ellipsoid, this attribute should not be defined. Example: "6371007", which is the radius of the GRS 1980 Authalic Sphere.

ellipsoid_name

Used to specify the name of the ellipsoidal figure associated with the geodetic datum and used to approximate the shape of the Earth. The value of this attribute is not standardised by this convention, except that for coordinates based upon a spherical Earth approximation the value sphere should be used. Example: "GRS 1980".

inverse_flattening

Used to specify the inverse flattening (1/f) of the ellipsoidal figure associated with the geodetic datum and used to approximate the shape of the Earth. The flattening (f) of the ellipsoid is related to the semi-major and semi-minor axes by the formula f = (a-b)/a. In the case of a spherical Earth this attribute should be omitted or set to zero. Example: 298.257222101 for the GRS 1980 ellipsoid. (Note: By convention the dimensions of an ellipsoid are specified using either the semi-major and semi-minor axis lengths, or the semi-major axis length and the inverse flattening. If all three attributes are specified then the supplied values must be consistent with the aforementioned formula.)

longitude_of_prime_meridian

Specifies the longitude, with respect to Greenwich, of the prime meridian associated with the geodetic datum. The prime meridian defines the origin from which longitude values are determined. Not to be confused with the projection origin longitude (cf. longitude_of_projection_origin, a.k.a. central meridian) which defines the longitude of the map projection origin. Domain: -180.0 <= longitude_of_prime_meridian < 180.0 decimal degrees. Default = 0.0

perspective_point_height

Records the the height, in metres, of the map projection perspective point above the ellipsoid (or sphere). Used by perspective-type map projections, for example the Vertical Perspective Projection, which may be used to simulate the view from a Meteosat satellite.

semi_major_axis

Specifies the length, in metres, of the semi-major axis of the ellipsoidal figure associated with the geodetic datum and used to approximate the shape of the Earth. Commonly denoted using the symbol a. In the case of a spherical Earth approximation this attribute defines the radius of the Earth. See also the inverse_flattening attribute.

semi_minor_axis

Specifies the length, in metres, of the semi-minor axis of the ellipsoidal figure associated with the geodetic datum and used to approximate the shape of the Earth. Commonly denoted using the symbol b. In the case of a spherical Earth approximation this attribute should be omitted (the preferred option) or else set equal to the value of the semi_major_axis attribute. See also the inverse_flattening attribute.

A new column for Type is to be added to the table, indicating the data type of each attribute, as in Table A.1. The following text is needed to explain the new column:

The "Type" values are S for string and N for numeric.

All the attributes have type N except for crs_name, ellipsoid_name, geodetic_datum_name and projection_name, which have type S.

Amendment to Appendix F, Table F.1, Grid Mapping Attributes

Attribute

Definition

standard_parallel

Specifies the line, or lines, of latitude at which the developable map projection surface (plane, cone, or cylinder) touches the reference sphere or ellipsoid used to represent the Earth. Since there is zero scale distortion along a standard parallel it is also referred to as a "latitude of true scale". In the situation where a conical developable surface intersects the reference ellipsoid there are two standard parallels, in which case this attribute can be used as a vector to record both latitude values, with the additional convention that the standard parallel nearest the pole (N or S) is provided first. Domain: -90.0 <= standard_parallel <= 90.0 decimal degrees.

Retitling of the subsections of Appendix F

The description of each grid_mapping_name described in Appendix F (albers_conical_equal_area, azimuthal_equidistant etc.) should constitute an unnumbered subsection of the appendix. At the moment they are given titles of "Example", but that is an error which was introduced when the CF standard document was translated into its present form. They are subsections, not examples.

Addition of grid_mapping subsections to Appendix F

Latitude-Longitude

grid_mapping_name = latitude_longitude

This grid mapping defines the canonical 2D geographical coordinate system based upon latitude and longitude coordinates on a spherical Earth. It is included so that the figure of the Earth can be described.

Map parameters: None.

Map coordinates:

The rectangular coordinates are longitude and latitude identified by the usual conventions (Sections 4.1 and 4.2).

Vertical perspective

grid_mapping_name = vertical_perspective

Map parameters:

• latitude_of_projection_origin
• longitude_of_projection_origin
• perspective_point_height
• 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:

Notes on using the PROJ.4 software packages for computing the mapping may be found at ​http://www.remotesensing.org/geotiff/proj_list/geos.html. These notes assume the point of perspective is directly over the equator. A more general description of vertical perspective projection is given in [Snyder], pages 169-181.

New examples in Section 5.6, Grid Mappings and Projections

Example. Latitude and longitude on a spherical Earth.

dimensions:
  lat = 18 ;
  lon = 36 ;
variables:
  double lat(lat) ;
  double lon(lon) ;
  float temp(lat, lon) ;
    temp:long_name = "temperature" ;
    temp:units = "K" ;
    temp:grid_mapping = "crs" ;
  int crs ;
    crs:grid_mapping_name = "latitude_longitude"
    crs:crs_name = "Spherical 2D Coordinate System" ;
    crs:ellipsoid_name = "sphere" ;
    crs:semi_major_axis = 6371000.0 ;
    crs:inverse_flattening = 0 ;

Example. Latitude-Longitude on the WGS 1984 Datum.

As in the previous example except for the grid_mapping variable:

  int crs ;
    crs:grid_mapping_name = "latitude_longitude";
    crs:crs_name = "WGS 84" ;
    crs:longitude_of_prime_meridian = 0.0 ;
    crs:ellipsoid_name = "WGS 84" ;
    crs:semi_major_axis = 6378137.0 ;
    crs:inverse_flattening = 298.257223563 ;

Example. British National Grid.

dimensions:
  lat = 648 ;
  lon = 648 ;
  y = 18 ;
  x = 36 ;
variables:
  double x(x) ;
    x:standard_name = "projection_x_coordinate" ;
    x:units = "m" ;
  double y(y) ;
    y:standard_name = "projection_y_coordinate" ;
    y:units = "m" ;
  double lat(y, x) ;
  double lon(y, x) ;
  float temp(y, x) ;
    temp:long_name = "temperature" ;
    temp:units = "K" ;
    temp:coordinates = "lat lon" ;
    temp:grid_mapping = "crs" ;
  int crs ;
    crs:grid_mapping_name = "transverse_mercator";
    crs:crs_name = "OSGB 1936 / British National Grid" ;
    crs:ellipsoid_name = "Airy 1830" ;
    crs:semi_major_axis = 6377563.396 ;
    crs:semi_minor_axis = 6356256.910 ;
    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 ;

Additions to Bibliography

[OGP/EPSG] ​http://www.epsg.org/ and ​http://www.epsg-registry.org/

[Snyder] J Snyder. 1987. "Map Projections -- A Working Manual", USGS Professional Paper 1395.

Change to conformance document

New requirements for 5.6

• The data types of the attributes of the grid mapping variable must be as specified in Table 1 of Appendix F.

[edavis]

Hi Jonathan,

Just four comments:

1) I think crs_name and ellipsoid_name should be removed or the definitions should say that they are only to be used as a human-readable label and specifically that certain values don't imply the values of any other attributes. Also, in the ellipsoid_name definition, the value "sphere" should not be explicitly suggested as there are a number of possible named spheres (with EPSG codes).

2) Should we have default values for the ellipsoid attributes? Clients are going to have to assume something if the attributes are missing.

3) To your new sentence in the Appendix F preamble, we should change "describe the ellipsoid" to "describe the ellipsoid and prime meridian".

4) If we are going to add "latitude_longitude", we should extend the CF Grid Mapping concept to include the more general CRS concept. As it stands "Grid Mapping" is specifically defined for mapping between x(x)/y(y) and lat(x,y)/lon(x,y). It is not defined for specifying the CRS of lat(lat)/lon(lon). This should be a pretty minor change I think. So, here's my suggested changes:

---

Change the title of Section 5.6

5.6 Horizontal Coordinate Reference Systems, Grid Mappings, and Projections

Add the following paragraph as the second paragraph in Section 5.6

When the coordinate variables for a horizontal grid are longitude and latitude, the horizontal coordinate reference system (CRS) may be described using the grid_mapping attribute. In particular, the latitude_longitude grid mapping should be used to specify the ellipsoid and prime meridian attributes.

---

That is it for me. Looks good otherwise.

Ethan

[jonathan]

Dear Ethan

1. refers to the text Phil proposed but has not been commented on before. In order to draw a conclusion on this ticket, I don't think we should debate it. Hence, I think we should remove crs_name and ellipsoid_name from the additions to be made to Appendix F. If required, they should be reproposed in a new ticket.

2. could be said about other optional attributes as well. It is not mandatory to define the ellipsoid. For instance in GCMs a realistic ellipsoid probably has not been considered at all and the radius of the Earth is not generally important for analysis or recorded in the model output. Hence, I think we can leave this silent but defaults could be proposed in a new ticket.

3. Thanks for picking that up. New text appended.

4. Thanks for picking that up too. New text appended - a simplified version of yours.

In view of these changes, I am reopening the ticket for three weeks (following the rules) so further comments can be made. Velimir, please don't make the changes yet. The proposal is now as in my last summary, as modified here. I'd like to ask people only to append to this ticket if they object to any of it. For additions, please could you wait until we have concluded this ticket, then open new ones. Thanks.

Cheers

Jonathan

Addition to preamble of Appendix F, Grid Mappings

Append to the first paragraph: "The attributes which describe the ellipsoid and prime meridian may be included, when applicable, with any grid mapping."

Change the title of Section 5.6

5.6 Horizontal Coordinate Reference Systems, Grid Mappings, and Projections

Add the following paragraph as the second paragraph in Section 5.6

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.

[jonathan]

Dear Phil, Velimir and all

There have been no further comments for three weeks on the present summary of Phil's ticket. Therefore the discussion is concluded, and I'm going to close this ticket again. Velimir, please could you make the changes required? There are changes in in the standard document (to be marked as provisional) and the conformance document; the version number should be incremented, and Phil should be added to the list of Additional Authors. The changes are as detailed in my long posting of 03/20/08 12:42:50, modified by my posting of 03/21/08 01:01:32. (Please ask me by email if these are not clear.)

The addition of name/id attributes and of new grid mappings could now be proposed in new tickets. Thanks to all concerned for your work on this one.

Jonathan