Add missing CF parameters to translate Coordinate Reference System properties to/from OGC Well-Known Text format

[etourigny]

1. Title

Add missing CF parameters to translate Coordinate Reference System properties to/from OGC Well-Known Text format.

2. Moderator

Jonathan Gregory

3. Requirement

CF-1.6 grid mapping parameters do not allow to fully represent Geographic and Projected Coordinate Reference System (CRS) definitions in Open Geospatial Consortium (OGC) Well-Known Text format.

The following WKT nodes cannot be transformed to/from CF-1.6: PROJCS, GEOGCS, DATUM, SPHEROID, TOWGS84, PRIMEM. In particular the absence of parameters that correspond to DATUM and TOWGS84 parameters can cause datum shifting errors.

Adding new parameters to the CF grid_mapping specification would allow to translate projected and geographic CRS WKT definitions to/from CF grid_mapping definitions without loss of information.

This is a simpler and easier approach than including the full OGC WKT string (as proposed in CF Metadata trac ticket #69) and detecting the potential conflicts between the CF and WKT definitions.

4. Initial Statement of Technical Proposal

The following grid mapping attributes would be added and described in Table F1

• horizontal_datum_name
• towgs84 (a double-precision array, with 3, 6 or 7 values)
• prime_meridian_name
• reference_ellipsoid_name
• projected_coordinate_system_name
• geographic_coordinate_system_name

The rationale for adding the various name parameters is to ensure a 100% compatibility between OGC WKT definitions and CF grid_mapping definitions and also to make the CF definitions more representative. In general, the names should be equal to the ones used in the EPSG database (see <OGP/EPSG>).

Named datums are particularly troublesome, as there is no unique naming scheme in OGC WKT (see <link2> and <CT>). The use of TOWGS84 parameters (inside a DATUM node) allow to approximate datum shifts to the WGS84 datum, but if precise datum shifts are required (using datum shift grids), then it is important that the datums are uniquely identified. It is required to follow the OGR/Cadcorp naming scheme described in the horizontal_datum_name entry for table F1 below (to ensure compatibility with Simple Features and CT specifications).

For reference the names and parameters of PRIMEM and SPHEROID entries from the EPSG database are provided in <link1> (prime_meridian.csv and ellipsoid.csv). DATUM entries, along with their transformed names and preferred TOWGS84 parameters are given in <link1> (horiz_datum.csv).

A similar proposal could be made to account for vertical CRS (VERT_CS in WKT), but this is outside the scope of this proposal.

As an example, the modified “British National Grid” example below would loose information if it were converted to and from CF-1.6:

PROJCS["unnamed",
    GEOGCS["unknown",
        DATUM["unknown",
            SPHEROID["Spheroid",6377563.396,299.3249646000044]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433]],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["latitude_of_origin",49],
    PARAMETER["central_meridian",-2],
    PARAMETER["scale_factor",0.9996012717],
    PARAMETER["false_easting",400000],
    PARAMETER["false_northing",-100000],
    UNIT["metre",1]]

The PROJCS, GEOGCS, DATUM and SPHEROID names are lost, but more importantly the TOWGS84 parameters also. The SPHEROID and PRIMEM parameters are recovered due to existing CF grid_mapping parameters, and the PRIMEM name is restored because Greenwich corresponds to longitude_of_prime_meridian = 0.

Changes to section 5.6

<at the end of 1st paragraph>
The translation of CF coordinate variables to/from OGC Well-Known Text (WKT) format is summarized in a few examples below and described in detail in <link1>. 

Example 5.9. Latitude and longitude on the WGS 1984 datum

<CF definition>

OGC WKT :

GEOGCS["WGS 84",
        DATUM["WGS_1984",
        SPHEROID["WGS 84",6378137,298.257223563]],
    PRIMEM["Greenwich",0],
    UNIT["degree",0.0174532925199433]]

Example 5.10. British National Grid
<...>
	char crs ;
		crs:grid_mapping_name = "transverse_mercator" ;
		crs:longitude_of_central_meridian = -2. ;
		crs:false_easting = 400000. ;
		crs:false_northing = -100000. ;
		crs:latitude_of_projection_origin = 49. ;
		crs:scale_factor_at_central_meridian = 0.9996012717 ;
		crs:longitude_of_prime_meridian = 0. ;
		crs:semi_major_axis = 6377563.396 ;
		crs:inverse_flattening = 299.324964600004 ;
		crs:projected_coordinate_system_name = "OSGB 1936 / British National Grid" ;
		crs:geographic_coordinate_system_name = "OSGB 1936" ;
		crs:horizontal_datum_name = "OSGB_1936" ;
		crs:reference_ellipsoid_name = "Airy 1830" ;
		crs:prime_meridian_name = "Greenwich" ;
		crs:towgs84 = 375., -111., 431., 0., 0., 0., 0. ;

OGC WKT :

PROJCS["OSGB 1936 / British National Grid",
    GEOGCS["OSGB 1936",
        DATUM["OSGB_1936",
            SPHEROID["Airy 1830",6377563.396,299.3249646000044],
            TOWGS84[375,-111,431,0,0,0,0]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433]],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["latitude_of_origin",49],
    PARAMETER["central_meridian",-2],
    PARAMETER["scale_factor",0.9996012717],
    PARAMETER["false_easting",400000],
    PARAMETER["false_northing",-100000],
    UNIT["metre",1]]

Changes to Table F1

Attribute	Type	Description
horizontal_datum_name	S	The name of the geodetic (horizontal) datum, which corresponds to the procedure used to measure positions on the surface of the Earth. Valid datum names and their associated parameters are given in <link1> (horiz_datum.csv, OGC_DATUM_NAME column) and are obtained by transforming the EPSG name using the following rules (used by OGR and Cadcorp): convert all non alphanumeric characters (including +) to underscores, then strip any leading, trailing or repeating underscores. This is to ensure that named datums can be correctly identified for precise datum transformations (see <link2> for more details). Corresponds to a OGC WKT DATUM node name.
towgs84	N	This indicates a list of up to 7 Bursa Wolf transformation parameters., which can be used to approximate a transformation from the horizontal datum to the WGS84 datum. More precise datum transformations can be done with datum shift grids. Represented as a double-precision array, with 3, 6 or 7 values (if there are less than 7 values the remaining are considered to be zero). Corresponds to a OGC WKT TOWGS84 node.
prime_meridian_name	S	The name of the prime meridian associated with the geodetic datum. Valid names are given in <link1> (prime_meridian.csv). Corresponds to a OGC WKT PRIMEM node name.
|reference_ellipsoid_name	S	The name of the reference ellipsoid. Valid names are given in <link1> (ellipsoid.csv). Corresponds to a OGC WKT SPHEROID node name.
geographic_coordinate_system_name	S	The name of the geographic coordinate system (GCS). Corresponds to a OGC WKT GEOGCS node name.
projected_coordinate_system_name	S	The name of the projected coordinate system (PCS). Corresponds to a OGC WKT PROJCS node name.

Changes to References

• <link1> ​http://cf-trac.llnl.gov/trac/wiki/Cf2CrsWkt
• <link2> ​http://home.gdal.org/projects/opengis/wktproblems.html
• <CT> OpenGIS Coordinate Transformation Service Implementation Specification 1.0 ​http://www.opengeospatial.org/standards/ct

5. Benefits

By implementing this proposal, we should assure that data producers and software developers can include most of the datum information and other decriptive properties of specific projections.

This proposal is much simpler and easier to manage than the proposal in trac ticket #69, which is entirely optional and has failed to reach consensus so far.

6. Status Quo

Data producers are forced to add custom WKT entries to their data files without any standard, which does not promote interoperability.

[jonathan]

Dear Etienne

Thank you for making this proposal and the great deal of work that you and Phil have invested in writing the wiki page. Your csv files will also be valuable to users of CF for reference. If this proposal is adopted, we should ensure all these resources are kept in permanent homes and properly linked from the CF website.

I hope others with appropriate expertise will comment on this proposal.

Cheers

Jonathan

[markh]

Hello Etienne

firstly I am very pleased to see the work invested in cataloguing. I echo Jonathan's desire to maintain these resources to ensure that the work can be beneficial long after your initial efforts.

I feel that the proper definition of the datum for a coordinate reference system needs a little more than CF currently provides.

I agree that the 6 grid mapping attributes in section 4 should be added to CF.

I am not sure I would put examples of translating between grid_mapping and WKT inside the CF specification; I think the CF spec should define the use of grid_mapping variables and attributes. I would put the details of translating between these encodings elsewhere.

From your examples you are inferring the nested structure used in WKT from the flat attribute list used in CF.

In your WKT and CF examples of OSGB, the WKT contains two 'units', one for the GeogCS and one for the ProjCS. These are not included in the CF: are they always alble to be inferred, does CF provide the details on how to infer this?

Please could you elaborate a little on how this is achieved?

If the key information is contained in the attribute names, should this be documented, alongside the names, within the CF specification?

also:

|reference_ellipsoid_name

contains a '|' at the start of the name, which I presume is a typo

[etourigny]

Replying to markh:

Hello Etienne

firstly I am very pleased to see the work invested in cataloguing. I echo Jonathan's desire to maintain these resources to ensure that the work can be beneficial long after your initial efforts.

Hi Mark, sorry for not responding earlier - I never got a message from trac! Thanks for your support.

I feel that the proper definition of the datum for a coordinate reference system needs a little more than CF currently provides.

I agree that the 6 grid mapping attributes in section 4 should be added to CF.

good!

I am not sure I would put examples of translating between grid_mapping and WKT inside the CF specification; I think the CF spec should define the use of grid_mapping variables and attributes. I would put the details of translating between these encodings elsewhere.

Do you refer to specific examples (which are necessary in my opinion) or the notes in the table? Should these then go in a wiki page, linked in the CF spec as a reference?

From your examples you are inferring the nested structure used in WKT from the flat attribute list used in CF.

I'm not sure I understand completely. Do you mean that the examples are sufficient to explain the translations, so no need to add translation comments in table F1?

In your WKT and CF examples of OSGB, the WKT contains two 'units', one for the GeogCS and one for the ProjCS. These are not included in the CF: are they always alble to be inferred, does CF provide the details on how to infer this?

Please could you elaborate a little on how this is achieved?

from the CT 1.0 spec document

7.3.19 UNIT
This describes units used for values elsewhere within the parent WKT clause (sometimes
including descendants of the parent clause).
The physical dimension (i.e. type) of the units is determined by context. For example, in a
GEOGCS the type of the units is angular. In a VERT_CS the type of the units is linear.
Within a UNIT clause, the units are described by relating them to a fundamental unit of that type
with a conversion factor. For linear units, the conversion factor is the scalar value that converts
the described units into meters. For angular units, the conversion factor is the scalar value that
converts the described units into radians.

for a GEOGCS node, UNIT["degree",0.0174532925199433]] is the most common (it's value is PI/180), no need to translate it to/from CF. Not sure how to handle other types (i.e. radians) though - this might require transforming all angular values, including PM.

For a PROJCS the units value is usually in in m or km. This is encoded in the CF coordinates "unis" attribute. The default "m" could assumed if there is no "units" attribute in the coord variable. In the example, CF x:units="m" corresponds to WKT UNIT["metre",1]]:

  double x(x) ;
    x:standard_name = "projection_x_coordinate" ;
    x:units = "m" ;

If the key information is contained in the attribute names, should this be documented, alongside the names, within the CF specification?

The key information is in the value of the attribute, so for example if the PROJCS units would be km the corresponding node could be UNIT["km",1000]]. Perhaps we could add the CT 1.0 wording above or similar, which would be sufficient to explain how they relate to CF units attributes.

also:

|reference_ellipsoid_name

contains a '|' at the start of the name, which I presume is a typo

yes

[jonathan]

Dear Mark and Etienne

As far as I can see, the proposal is OK as it stands, apart from the typo Mark pointed out. I believe that in the CF equivalents the units are either defined by the attribute definition, or stated by a units attribute. If the units were not degrees for a geographical coordinate system, they would have be translated to degrees_north and degrees_east, since CF requires latitude and longitude to have these units; udunits permits radians to be translated into degrees_east and degrees_north.

Are there any further comments on this proposal?

Jonathan

[etourigny]

Jonathan - do you propose any text or changes to CF regarding units handling CF<->WKT?

i.e. a short paragraph somewhere explaining how units are translated, depending on if the CRS is a projected or geographic one?

How do you define the units by the attribute definition?

[jonathan]

Dear Etienne

No, I don't propose any changes to your CF text. Since the question has been raised, I agree it would be helpful to add a remark about the units translation, but since this is an issue for CF<->WKT translation rather than for CF itself, you could put that remark in the wiki page about the translation. What I mean by the units being defined by the attribute is that, for instance, the definition of grid_north_pole_latitude in Appendix F says it is in degrees_north, and semi_major_axis says it is in metres. However, now that I look at it, I see it's not defined in all cases, and it should be. I would therefore like to add to your proposal, as follows:

Amend the definition in Appendix F for latitude_of_projection_origin by appending "Units: degrees_north, and for longitude_of_central_meridian, longitude_of_prime_meridian, longitude_of_projection_origin, straight_vertical_longitude_from_pole by appending "Units: degrees_east.

This hasn't been clarified before because it has been implicit, I think.

Thanks

Jonathan

[etourigny]

ok - you mean modifying table F1 right?

Also north_pole_grid_longitude should have degrees_north instead of degrees

example:

latitude_of_projection_origin	N	 The latitude (degrees_east) chosen as the origin of rectangular coordinates for a map projection. Domain: -90.0 <= latitude_of_projection_origin <= 90.0

longitude_of_central_meridian	N	 The line of longitude (degrees_north) at the center of a map projection generally used as the basis for constructing the projection. Domain: -180.0 <= longitude_of_central_meridian < 180.0

or this?

latitude_of_projection_origin	N	 The latitude chosen as the origin of rectangular coordinates for a map projection. Units: degrees_east, Domain: -90.0 <= latitude_of_projection_origin <= 90.0 

longitude_of_central_meridian	N	 The line of longitude at the center of a map projection generally used as the basis for constructing the projection.  Units: degrees_north, Domain: -180.0 <= longitude_of_central_meridian < 180.0.

[jonathan]

Dear Etienne

Yes, that's what I meant, thanks. Either way of inserting it would be fine with me. However, I think north_pole_grid_longitude should remain in degrees, because it is not a longitude but a grid_longitude, whose units (in the standard name table) are degrees.

Jonathan

[etourigny]

Based on a discussion with Martin Desruisseaux and Jonathan Gregory, references to "coordinate system" should be replaced by "coordinate reference system" (or "crs") as they refer to different concepts.

Therefore, the last entries in table F1 above should read

geographic_crs_name	S	The name of the geographic coordinate reference system. Corresponds to a OGC WKT GEOGCS node name.
projected_crs_name	S	The name of the projected coordinate reference system. Corresponds to a OGC WKT PROJCS node name.

[lowry]

Although this is not my specialist subject, I think the benefits delivered by this straightforward change are such that I would like to see it taken forward.

[jonathan]

Dear all

This ticket has no outstanding objections and has received sufficient support to be accepted according to the rules. It will be accepted on 8th August, which is three weeks from the last update to the proposal, and almost two months since I last invited comments, unless anyone objects before then. The current form of the proposal is as Etienne originally put it, with the typo noted by Mark on 22nd March, and the modifications noted on 14th June and 18th July.

Cheers

Jonathan

[mgschultz]

Dear Jonathan and all,

just back from vacation I saw this newly revived discussion on track tickets #80 and #69. While I agree with this proposal in general and would like to express my support for it, I would like to see clarification on two points, without which I fear we will make many users unhappy (see comments by Paul Kennedy and Tim Hume on cf-metadata email list):

1) the main issue is how "strictly" this proposal shall be applied, or in other words: what is the minimum valid CRS definition? Several emails have stressed the importance of EPSG in this field, and I guess most of us would be happy to leave the "dirty work" to the experts and be done with a simple crs:epsg_code = 4326. By mandating the specification of extra attributes which may duplicate information from the EPSG (or WKT) descriptions, you risk additional errors due to typos, differing round-offs, etc. So, in view of ticket #90, I suggest to review the current proposal once more in terms of which attributes are required, conditional, or optional (in interoperable frameworks). Perhaps naively, I would tend to think that "crs" as such should be mandatory, but then it should suffice to make the epsg_code reference. I have too little knowledge about the geographic projection issues to make any informed suggestions about which of the other parameters are required (once you start using them). For example: if you do specify a prime_meridian_name, do you then have to also specify the reference_ellipsoid_name, or are these two completely independent and a CRS definition can be complete with only one of them.

2) If this proposal shall make it into the CF conventions, I suggest to add some explanatory text which at a minimum points out:

1. why a crs is needed

2. that there are two major standard groups (is this actually correct?), namely EPSG and OGC-WKT [and what is their relation; plus web links]

3. that coarse-resolution model data (still the main application area of CF data) generally uses a spherical earth and only requires a simple projection information (e.g. the epsg_code attribute)

Another side-note: I actually doubt that the current practice of specifying EPSG=4326 is correct. I had an email exchange with Roger Lott about this (see ​http://wiki.esipfed.org/index.php/CRS_Specification).

Best regards,

Martin

[etourigny]

Replying to mgschultz:

Dear Jonathan and all,

just back from vacation I saw this newly revived discussion on track tickets #80 and #69. While I agree with this proposal in general and would like to express my support for it, I would like to see clarification on two points, without which I fear we will make many users unhappy (see comments by Paul Kennedy and Tim Hume on cf-metadata email list):

Hi Martin,

Perhaps you sould also join in the recent discussion on the mailing list which you mention.

1) the main issue is how "strictly" this proposal shall be applied, or in other words: what is the minimum valid CRS definition? Several emails have stressed the importance of EPSG in this field, and I guess most of us would be happy to leave the "dirty work" to the experts and be done with a simple crs:epsg_code = 4326. By mandating the specification of extra attributes which may duplicate information from the EPSG (or WKT) descriptions, you risk additional errors due to typos, differing round-offs, etc. So, in view of ticket #90, I suggest to review the current proposal once more in terms of which attributes are required, conditional, or optional (in interoperable frameworks). Perhaps naively, I would tend to think that "crs" as such should be mandatory, but then it should suffice to make the epsg_code reference. I have too little knowledge about the geographic projection issues to make any informed suggestions about which of the other parameters are required (once you start using them). For example: if you do specify a prime_meridian_name, do you then have to also specify the reference_ellipsoid_name, or are these two completely independent and a CRS definition can be complete with only one of them.

That's a good point - I didn't really think about it, since there is no mention of this in the CF. Is the radius value mandatory, etc?

I would stress that all of the *name* parameters are purely optional, and are proposed for interoperability with WKT definitions. Without these additions, you cannot express a WKT reliably in CF, and get it back properly in WKT, or define a CF that could be translated to WKT.

The extra parameter towgs84 is mandatory, in the case that the CRS requires a parameter for it to be translated into the WGS84 reference system. However, probably 99% of CF files (especially on a spherical earth) do not require this parameter.

In terms of the names being mandatory, I would propose that reference_ellipsoid_name,prime_meridian_name, horizontal_datum_name and geographic_crs_name must be all defined if any one is, along with projected_crs_name if the crs is a projected one. This would make definitions consistent. Either use them all, or none.

Also, when you are defining datum parameters (not datum transformation), all values should be included, so I would suggest they be mandatory if there is a crs definition: longitude_of_prime_meridian,semi_major_axis,inverse_flattening/semi-minor-axis

However, I wonder if this fits the scope of this proposal, because we mightg have to review all of the parameters and decide if they are mandatory or optional.

Now concerning EPSG codes.

Firstly they do not fit well in the CF model, because you need to consult external tables/definitions to get the values associated with them. Their imlementation in CF would require either the addition of definitions inside CF (using a standard table) or the use of an external service, such as spatialreference.org or epsg-registry.org .

Secondly, the adoption of EPSG is also outside of the scope of this proposal, and would require a trac ticket on its own. There is too much dissent (see past discussions on the mailing on this subject, before the recent one), so I'm not willing to go down that route. The major problem with EPSG is that you cannot realistically blend EPSG codes with any CRS definitions in CF, so they would have to be proposed as alternatives. And that would require a means for a machine to fill in the values that correspond to an EPSG code. Software such as gdal/ogr does that.

Thirdly, the example you cite of a spherical earth doesn't need an EPSG code or the modifications included in this proposal at all, because it has an existing CF definition:

Example 5.8. Latitude and longitude on a spherical Earth    crs:grid_mapping_name = "latitude_longitude"
...
  int crs ;
    crs:grid_mapping_name = "latitude_longitude"
    crs:semi_major_axis = 6371000.0 ;
    crs:inverse_flattening = 0 ;

But this example it's missing crs:longitude_of_prime_meridian = 0.0 ; -> we should add this as a change also.

So I guess to make everyone happy we could recommend to use the spherical earth definition if the data if from a model, or the WGS84 definition if coming from observations (e.g. global satellites).

2) If this proposal shall make it into the CF conventions, I suggest to add some explanatory text which at a minimum points out:

1. why a crs is needed

to describe the coordinate reference system with full accuracy.

2. that there are two major standard groups (is this actually correct?), namely EPSG and OGC-WKT [and what is their relation; plus web links]

These standards are linked in this proposal : <link2> and <CT> as well as EPSG in CF-1.6

3. that coarse-resolution model data (still the main application area of CF data) generally uses a spherical earth and only requires a simple projection information (e.g. the epsg_code attribute)

again, why have an EPSG code when 2 (or 3) parameters suffice?

Another side-note: I actually doubt that the current practice of specifying EPSG=4326 is correct. I had an email exchange with Roger Lott about this (see ​http://wiki.esipfed.org/index.php/CRS_Specification).

Now it's interesting that the email you mention, EPSG:4047 corresponds to the spherical earth models use, but again: no need for that in CF.

Best regards,

Martin

Jonathan: what is your view on this? Should the mandatory/recommended/conditional information be added? Should I/we prepare a short paragraph that answers some of these concerns in 2) and where to put it?

[caron]

Hi Etienne:

I appreciate the hard work that this ticket represents (thanks!!), and Im not happy with duplicating the work that has gone into WKT already. Im guessing that many, many more hours will go into getting this right, and then there will be a new thing not yet covered.

So I would propose that we accept ticket #69 along with ticket #80, or perhaps merge them together along these lines:

1) we accept #69 which says "heres where to put your WKT if you have one".

2) ticket #80 becomes the framework in which we translate WKT parameters to CF attributes. What is already there is much appreciated.

3) We write conformance tests to test that the WKT is consistent with the parameters, if they both exist.

In this way, data writers with existing WKT can immediately do something, with no further effort. Others can use start to use the #80 attributes. With translating software, we can start to generate the attributes from the WKT, and flag problems or things not yet encoded in attributes.

john

[rsignell]

John, This sounds to me like a very reasonable balance between the CF ideals and pragmatism.

ESRI and GDAL have been writing WKT strings into their NetCDF files for the last 5 years or so, and it would be nice to have a CF-acceptable way to do it.

-Rich

[jonathan]

Dear all

I think this ticket should be accepted when there are no outstanding comments on its content. In answer to Etienne's question, I think it would be fine to modify the proposal to introduce some requirements or recommendations which could be added to the CF conformance document, following Martin's comment. It seems to me that this proposal fills a need that has been outstanding for a long time, and it demonstrably works since Etienne has software which implements it. No doubt it does not cover all conceivable cases, but CF never aims to do that; we expand the convention as we need to.

The decision about ticket 69 should be made separately. These are alternatives for CF. Both could be accepted (separately). My main reservation about 69 is the possibility for inconsistency, and that is why I have argued in that ticket that, if WKT is included, CF grid_mapping attributes should not be allowed, in order to avoid that inconsistency. But that discussion is on ticket 69 and I shouldn't mix up the two, especially as I'm moderating this one only!

Cheers

Jonathan

[pbentley]

Replying to jonathan:

It seems to me that this proposal fills a need that has been outstanding for a long time, and it demonstrably works since Etienne has software which implements it.

I'm not convinced the latter point is relevant here. As Rich alludes to above, and as I mentioned in ticket 69, other netcdf software tools have been utilising the WKT approach for a number of years. Indeed that was one of the motivating factors for wanting to incorporate it into the CF standard.

The decision about ticket 69 should be made separately. These are alternatives for CF. Both could be accepted (separately).

The proposal in ticket 69 received widespread endorsement. As the principal objector, if you were to withdraw your objections then it could be accepted without further ado! Are you content to do that?

My main reservation about 69 is the possibility for inconsistency, and that is why I have argued in that ticket that, if WKT is included, CF grid_mapping attributes should not be allowed, in order to avoid that inconsistency.

As the author of ticket 69 it won't come as much surprise to learn that I still consider the WKT approach to represent the more effective and elegant solution (though I'd be happy to support both options if that is the best outcome we can achieve).

My chief reservations regarding the current proposal are:

• It unnecessarily imports a number of new attributes into the CF standard when this can be achieved concisely, and with no loss of information, using the compact string notation defined by the CRS WKT standard.

• The current proposal only covers a subset of the possible elements which could be encoded in a CRS WKT string. For example, I may have a dataset whose CRS requires specification of the parameter 'geocentric X of topocentric origin'. There are other such parameters, some admittedly more specialised than others. The WKT approach would enable definition of such elements without having to repeatedly update the CF standard.

• At the June 2012 meeting of the OGC CRS domain working group in Exeter, it was announced that the CRS WKT standard will be refreshed with a view to producing a new ISO/OGC CRS WKT 2.0 standard (see ​here). Some of the potential revisions to the standard that were mentioned at the meeting (such as the proposed removal of the TOWGS84 parameter) are likely to impact on the content of the current proposal.

Phil

[etourigny]

I Phil - nice to have your comments on this ticket!

Replying to pbentley:

Replying to jonathan:

It seems to me that this proposal fills a need that has been outstanding for a long time, and it demonstrably works since Etienne has software which implements it.

I'm not convinced the latter point is relevant here. As Rich alludes to above, and as I mentioned in ticket 69, other netcdf software tools have been utilising the WKT approach for a number of years. Indeed that was one of the motivating factors for wanting to incorporate it into the CF standard.

I believe that the two approaches can be complementary - ticket #80 allows for interoperability with WKT, while preserving existing CF syntax, and ticket #69 allows an alternative way (and more elegant, I agree) to express the CRS. I agree with Jonathan - if WKT is used then no other CF CRS parameters should be used, or perhaps they are invalidated.

The decision about ticket 69 should be made separately. These are alternatives for CF. Both could be accepted (separately).

The proposal in ticket 69 received widespread endorsement. As the principal objector, if you were to withdraw your objections then it could be accepted without further ado! Are you content to do that?

My main reservation about 69 is the possibility for inconsistency, and that is why I have argued in that ticket that, if WKT is included, CF grid_mapping attributes should not be allowed, in order to avoid that inconsistency.

As the author of ticket 69 it won't come as much surprise to learn that I still consider the WKT approach to represent the more effective and elegant solution (though I'd be happy to support both options if that is the best outcome we can achieve).

My chief reservations regarding the current proposal are:

• It unnecessarily imports a number of new attributes into the CF standard when this can be achieved concisely, and with no loss of information, using the compact string notation defined by the CRS WKT standard.

I think it is the only way to achieve interoperability without forcing to abandon CF-style CRS definition in favor of the WKT string approach. Forcing to use WKT instead of CF CRS would break many software.

• The current proposal only covers a subset of the possible elements which could be encoded in a CRS WKT string. For example, I may have a dataset whose CRS requires specification of the parameter 'geocentric X of topocentric origin'. There are other such parameters, some admittedly more specialised than others. The WKT approach would enable definition of such elements without having to repeatedly update the CF standard.

By all means, if there are new parameters they could be submitted - that's the CF way as I see it. I think that this proposal covers *most* use cases. If there are other parameters which should be included, then we can add it (them).

• At the June 2012 meeting of the OGC CRS domain working group in Exeter, it was announced that the CRS WKT standard will be refreshed with a view to producing a new ISO/OGC CRS WKT 2.0 standard (see ​here). Some of the potential revisions to the standard that were mentioned at the meeting (such as the proposed removal of the TOWGS84 parameter) are likely to impact on the content of the current proposal.

While I agree that WKT 2.0 is a great thing, I ponder: how much time (i.e. years) before it is 1) adopted formally 2) actually used in the community. This ticket (as well as #69) deal with present standards that are actually used. Also, you would have to revise ticket 69 so I don't see how relevant it is to the adoption of this one only. Admittedly, the adoption of WKT 2.0 in CF will require a separate ticket.

cheers Etienne

Phil

[jonathan]

Dear Phil

Sorry, I should not have commented on this ticket about ticket 69.

I think the point about existing software is relevant to this ticket, because it's been suggested in the past that it's good to have a demonstration of proposed extensions to CF working in practice. The rules say that changes remain provisional until they have been successfully shown to work, in the sense that software exists which can deal with netCDF files including the new convention. That's why I made the point.

I will be away for the next three weeks. Apologies in advance for not being able to contribute during that period.

Cheers

Jonathan

[caron]

Replying to jonathan:

Dear all My main reservation about 69 is the possibility for inconsistency, and that is why I have argued in that ticket that, if WKT is included, CF grid_mapping attributes should not be allowed, in order to avoid that inconsistency. But that discussion is on ticket 69 and I shouldn't mix up the two, especially as I'm moderating this one only!

Hi Jonathan, et al:

I think that WKT should be optional, and never replace our other mechanisms; grid_mapping attributes should take precedence if both are present; specialized software can issue warnings when there are inconsistencies, and also translate between the two, although sometimes incompletely.

in short:

1. having a standard place to put the WKT would be an important advance in pushing netcdf/CF into new GIS territory.
2. this GIS territory is too complicated to pull all of it into CF attributes, and we wont cover all the cases.
3. having the WKT when available will be useful to specialized software.

John

[jonathan]

Dear all

Various people have said that it would OK to have both a CF-style description and WKT in the grid_mapping, despite the possible inconsistency, and only I have argued that they should be mutually exclusive. Therefore I'll drop that argument and accept the majority view, and agree that both this ticket and ticket 69 should be accepted.

Etienne, would you like to add any requirements or recommendations to this proposal in response to Martin's comment? I believe this is the only outstanding question as regards the content of this proposal. Since the proposal has been modified a bit since the ticket began, it would be helpful if you could repeat it as it stands now.

Best wishes and thanks

Jonathan

[etourigny]

Jonathan,

What about pbentley's comments? I feel I have responded sufficiently, and present consensus on allowing both WKT (secondary) and new CF attributes is satisfactory.

I can add mandatory/recommended/conditional information to table F1 - should this be a new column or added to the end of the description?

Following's Mark's comment we should add a short paragraph, where should this go, in section 5.6 before Example 5.6?

I will prepare a final document based on all changes.

[jonathan]

Dear Etienne

On Mark's point, I think (as on 14th June) it would be OK to remark on units translation in the linked wiki page, since this is not part of the convention itself. We also agreed some changes in Table F1 at that time.

I would suggest that rules concerning what is mandatory/recommended should appear in the text of sect 5.6, since if I have understood correctly it is mostly about combinations of things, rather than referring to individual attributes. It would be helpful if at the same time you could draft the required changes to the CF conformance document ​http://cf-pcmdi.llnl.gov/conformance/requirements-and-recommendations/1.6.

I think Phil Bentley's concerns were matters of principle, rather than comment on the content of this proposal, and I hope that he will be content if both tickets are accepted.

Best wishes

Jonathan

[etourigny]

Replying to jonathan:

Dear Etienne

On Mark's point, I think (as on 14th June) it would be OK to remark on units translation in the linked wiki page, since this is not part of the convention itself. We also agreed some changes in Table F1 at that time.

I have updated the wiki with information on units.

I would suggest that rules concerning what is mandatory/recommended should appear in the text of sect 5.6, since if I have understood correctly it is mostly about combinations of things, rather than referring to individual attributes. It would be helpful if at the same time you could draft the required changes to the CF conformance document ​http://cf-pcmdi.llnl.gov/conformance/requirements-and-recommendations/1.6.

done - I will upload a final draft shortly

I think Phil Bentley's concerns were matters of principle, rather than comment on the content of this proposal, and I hope that he will be content if both tickets are accepted.

Best wishes

Jonathan

[etourigny]

final draft

[etourigny]

I have attached a final draft, hopefully adressing every concern.

I am hesitant about this statement in section 5.6, which I added in response to mgschultz . Perhaps it should be as a note to table F1 instead, or dropped entirely.

The following attributes should be included when there is a CRS (Coordinate Reference System) definition: longitude_of_prime_meridian (if different than 0), semi_major_axis and inverse_flattening or semi-minor-axis.

[jonathan]

Slightly modified version of Etienne's attachment

[jonathan]

Dear Etienne

Thank for the final draft. Since no-one has commented further and three weeks have passed, this ticket should be accepted and included in the next version of the CF standard. At that time, Etienne should be added to the list of additional authors.

Regarding your hesitation above, I would agree that it would be more logical to put it as a note to Table F1, where you have put some other remarks. I have therefore prepared a slightly modified version ​https://cf-pcmdi.llnl.gov./attachments/issue80-2.txt of your attachment, with this small change made. Is that OK with you?

We still need to consider what additions should be made to the conformance document. It seems to me that there are three, arising from these footnotes.

• reference_ellipsoid_name, prime_meridian_name, horizontal_datum_name and geographic_crs_name must be all defined if any one is defined.

• If projected_crs_name is defined then geographic_crs_name must be also.

• If there is a CRS (Coordinate Reference System) definition, semi_major_axis must be defined, and either inverse_flattening or semi_minor_axis must be defined.

We can't require longitude_of_prime_meridian in the last one, because there is a default. In this last point, what exactly does it mean to say there is a CRS definition? I mean, what formal criterion should the CF checker use to decide this?

Best wishes

Jonathan

[etourigny]

I agree with your revised draft, except for note (3) which I would drop entirely.

The main points of this ticket relate to adding missing parameters, not about making semi_major_axis inverse_flattening and semi_minor_axis mandatory. Indeed it would be a bit tricky deciding which CRS/grid_mapping definitions require radius values.

I would say offhand to make them mandatory in any grid_mapping definition, but that is probably very restrictive and cause some disruptions. This is indeed a problem in the CF standard - what is the default sphere radius if none is given? It should probably be addressed in another ticket/discussion, which I cannot start due to time constraints.

Cheers, Etienne

[jonathan]

with footnote (3) deleted

[jonathan]

Dear Etienne

OK. Then the ticket is concluded, with footnote (3) removed from the revised text, and the following two conditions to be added to section 5.6 of the conformance document.

• reference_ellipsoid_name, prime_meridian_name, horizontal_datum_name and geographic_crs_name must be all defined if any one is defined.

• If projected_crs_name is defined then geographic_crs_name must be also.

Many thanks for completing this.

Jonathan

[painter1]

The final draft, issue80.2.txt, includes two urls. The first, ​https://cf-pcmdi.llnl.gov/trac/wiki/Cf2CrsWkt, should be moved, perhaps to a wiki on github. It also should be updated. The second url, ​http://home.gdal.org/projects/opengis/wktproblems.html, no longer exists. I retrieved the latest version at archive.org, dated 2013. This too should be saved in a better place, perhaps also a github wiki.

[jonathan]

Dear Jeff

Yes, please. These documents should be adopted by CF and put somewhere on the web page for reference, as supplementary material to the convention.

Thanks

Jonathan

[painter1]

Tickets 69 and 80 overlapped,as both involved specifications in CRS/OGC WKT (well known text) format, section 5.6 and Appendix F. I had implemented ticket 69 over two years ago. But ticket 80 is even older, and seems to have been developed independently. I would like to invite anyone interested to review how I implemented ticket 80 on top of ticket 69, and offer his opinions. Combining these tickets mainly involved work in examples now numbered 5.9, 5.10, 5.11, and 5.12. They have been rearranged and conflicts resolved as best I could.

You can see the candidates for chapter 5 and Appendix F at these urls: Chapter 5: ​https://github.com/cf-convention/cf-conventions/blob/f55b154e1be688272880465cd0e138a6c4fa3f1e/ch05.adoc Appendix F: ​https://github.com/cf-convention/cf-conventions/blob/f55b154e1be688272880465cd0e138a6c4fa3f1e/appf.adoc

[jonathan]

Thanks for dealing with all this complexity so carefully. As far as I can see it's OK! Jonathan

[painter1]

The CF Conventions document, version 1.7 draft, now includes the changes specified in this ticket. The conformance document hasn't been revised as described in comment 28, so this ticket isn't ready to be closed.