Add an attribute in Appendix F to identify the geoid or other geopotential datum

[jonathan]

Some geophysical quantities, including some vertical coordinates, are defined with reference to the geoid. For example, the standard_name of altitude is the height above the geoid. CF does not have a default geoid, because the convention is used for both model-generated and real-world data, and climate models typically do not use a real-world geoid. When CF is used for real-world data, it may be necessary to desirable to specify which geoid is being used.

This proposal is to define a new attribute geoid_name to be included in the table of Appendix F for the legal attributes of the grid_mapping variable. This attribute will have type S (string) and its description will be "The name of the geoid. Corresponds to an OGC WKT VERT_DATUM name."

​Ticket 80, which was agreed a long time ago for inclusion in CF 1.7, also adds some attributes to Appendix F. This proposal is complementary to and consistent with that one.

Jonathan Gregory

[rsignell]

I support this ticket, and would be willing to moderate.

So since you specify OGC WKT, simple names of well-known datums (such as NAVD88) would not be compliant, right?

And neither would EPSG names, such as EPSG:5703 (NAVD88), right?

To be valid, we would require full OGC WKT like (for NAVD88):

VERT_CS["NAVD88 height",VERT_DATUM["North American Vertical Datum 1988",2005,AUTHORITY["EPSG","5103"],UNIT["metre",1,AUTHORITY["EPSG","9001"]],AXIS["Up",UP],AUTHORITY["EPSG","5703"]]

Is that the idea?

[jonathan]

Dear Rich

I'm proposing that we take the same approach as Etienne did with the other new attributes for Appendix F in ticket 80. That is, this attribute should contain a name, not a code, consistent with the general approach of CF that the metadata should be self-explanatory. For the horizontal datum names, ellipsoid names and prime meridian names, Etienne extracted a list of possibilities from the EPSG database. Please have a look at the attachments to ​https://cf-pcmdi.llnl.gov/trac/wiki/Cf2CrsWkt.

Could the same be done for geoid names? This is not something I know anything about, but perhaps someone else can extract a list of possible geoid names from EPSG? I think that providing such a list, as Etienne did for the other attributes, is a good means for CF to promote the use of another existing standard. Is "North American Vertical Datum 1988" the name of a geoid? If so I guess it would be one of the possible values for this attribute.

Cheers

Jonathan

[markh]

I recognise the need for the capability to define vertical datum instances for vertical coordinates to reference.

Generally a Geoid is used to define a 3D coordinate reference system, not just the vertical aspect. I assume that in the majority of cases we would want to define altitude with respect to a geoid which other coordinates are already defined with respect to.

• Are there use cases where we need to define altitude with respect to a datum which other coordinates are not defined with respect to?
• Is it valid OGC-WKT to define a WKT string which only defines a VERT_CS?

Given that we are introducing well known text support for grid_mapping instances in @CF-1.7, can we just use this mechanism, rather than producing an additional set of CF geoid names which will require maintenance by the community?

[jonathan]

Dear Mark

I don't think we should reopen the extremely lengthy and effortful discussions which we had before about how to approach the relationship with WKT. In the end, we agreed two tickets. Ticket 69 allows WKT to be included in the grid_mapping variable. It says, "The crs_wkt attribute is intended to act as a supplement to other single-property CF grid mapping attributes (as described in Appendix F); it is not intended to replace those attributes. If data producers omit the single-property grid mapping attributes in favour of the compound crs_wkt attribute, software which cannot interpret crs_wkt will be unable to use the grid_mapping information. Therefore the CRS should be described as thoroughly as possible with the single-property attributes as well as by crs_wkt." Ticket 80 adds some more attributes to grid_mapping so that more of the WKT can be put into CF attributes. Etienne (or perhaps it was Phil Bentley, I'm sorry I'm not sure which) extracted lists from the EPSG database for convenience of users. Those extracted lists themselves are not definitive; we're not maintaining a CF standard, but relying on an external standard.

The present ticket is a supplement to ticket 80, in effect. CF doesn't say anything about the legal syntax of WKT strings, because that's not our business. However, we do need a CF method to specify the geoid, for the sake of precision in defining coordinates which refer to the geoid.

If there is a grid_mapping attribute of the kind you can have in CF-1.6 and earlier versions, it applies to all the coordinates of the data variable. If you did want to use different geoids for different coordinates, that could be done with extended form of grid_mapping attribute that we agreed on a ticket of yours.

Cheers

Jonathan

[markh]

Replying to jonathan: Dear Jonathan

My comment was triggered by rsignell's point about storing OGC-WKT in this attribute. This seems to me to be unwise. If people are storing WKT, I think they should use the crs_wkt attribute.

I think that you are proposing something different, but I don't understand the information or the syntax which would be stored in the proposed attribute, how this would be controlled and validated.

Some examples of the kinds of strings that crs_wkt would refer to would help the discussion, for me.

thank you mark

[jonathan]

Dear Mark

I am not proposing anything different from what has already been decided in ticket 69. It is permitted to put any valid WKT in the crs_wkt attribute. CF doesn't standardise WKT, of course, and CF generic applications can't be expected to analyse WKT. You are much more familiar with WKT strings than I am, so I expect you have got examples!

The new attribute for grid_mapping that I am proposing is of exactly the same kind of those which have been agreed in ticket 80, to supplement those which we already have in App F. It is an attribute in which you can store the geoid name, that's all. I believe that the geoid name may be the string at the start of a VERT_DATUM clause in WKT if the vertical datum is a geoid, but as I say, I am no expert on WKT. Hence my question, is "North American Vertical Datum 1988" the name of a geoid? Does anyone know?

However, I don't think that the answer to that affects the proposal. Where the geoid name is recorded in WKT is not the issue in this proposal. The proposal is about an attribute in grid_mapping which is specifically intended to record the geoid name. If crs_wkt is provided as well, presumably the geoid name might be in there as well, and we can only hope they will be consistent. That is the same situation as for all the other attributes, and is what we decided to do in ticket 69 and 80. I don't think we should reopen that discussion, which took a long time and a lot of thought by several people.

Best wishes

Jonathan

[markh]

Replying to jonathan: It is not my intent to reopen old tickets regarding the definition of grid_mapping attributes.

I would like to understand the proposed contents of the new attribute, geoid_name; it is not clear to me what information this attribute would contain or how that information would be encoded.

[jonathan]

Dear Mark

Replying to jonathan: It is not my intent to reopen old tickets regarding the definition of grid_mapping attributes.

OK - good. Thanks. :-)

I would like to understand the proposed contents of the new attribute, geoid_name; it is not clear to me what information this attribute would contain or how that information would be encoded.

It is a string containing the name of the geoid. It's not encoded. This is how we store other names, such as the reference_ellipsoid_name attribute introduced by ticket 80, which likewise is a string which can also appear in the WKT. Have I misunderstood the question?

Jonathan

[jonathan]

Following discussion with Rich Signell, I would like to add a couple of examples of geoid_name, namely EGM96 and GEOID12B.

Jonathan

[rsignell]

Jonathan, I'm dragging my feet here because now I'm a bit confused about the utility of this ticket. I originally supported this because I thought this would be a way to specify heights relative to a gravity-based datum.

I had not realized that ticket ​http://cf-trac.llnl.gov./69 allowed the specification of the vertical coordinate system via VERT_CS, which is why I thought I was supporting this ticket.

Everyone who does river, lake or ocean modeling uses heights relative to a orthometric (gravity-based) datum (so that water flows down hill!), and folks in the US use NAVD88 (they used to use NGVD29). Neither of these are geoides, but they are intended to be gravity-based datums. So we need a way to say that our heights are in meters relative to NAVD88 or NGVD29, not relative to a GEOID.

This ticket allows for the geoid model to be identified (e.g. GEOID12B), but not for way to specify the vertical datum.

The CF Standard Name currently defines altitude as "Altitude is the (geometric) height above the geoid, which is the reference geopotential surface. The geoid is similar to mean sea level."

But perhaps we should define altitude as "Alitude is height above an orthometric (gravity-based) datum" and redefine this ticket to define a "vertical_datum", where NAVD88 would be one of the possible values (along with other gravity-based datums).

The very term geoid is a bit fuzzy, apparently: ​http://www.ngs.noaa.gov/GEOID/geoid_def.html Perhaps we should just provide a way to specify vertical datums that are commonly understood and used.

And in the meantime, I'll start using the crs_wkt`, since that will solve my problem immediately!

[jonathan]

Dear Rich and others

I understand the problem and I think we should be able to describe these coordinates in CF, but I'm still unclear what NAVD88 actually is. Orthometric height means relative to the geoid, doesn't it? What's the difference between a gravity-based datum and a geoid? Perhaps "gravity-based" means not geopotential (which includes Coriolis acceleration) but just gravitational potential, is that it? But that doesn't sound right because g in geophysics is usually a derivative of geopotential, not gravity, I believe. I hope that someone can help out with an explanation, since it seems unclear in EPSG and CRS WKT what these vertical datums mean in geophysical terms.

Best wishes and thanks

Jonathan

[rsignell]

Jonathan, I think NAVD88 is a vertical datum that is parallel to the GEOID12B representation of the geoid, but is offset so that it matches the International Great Lakes Datum of 1985 local mean sea level height value, at Rimouski, Quebec, Canada. I'm not sure what this offset is though.

I've asked Ed Myers at NOAA (who is responsible for the VDATUM software), and he in turn is asking some folks from NGS to take a look. Hopefully that will help us get to the bottom of this.

[jonathan]

That's great, thanks. If that is the case, then NAVD88 is a geopotential surface, but not a geoid. I think it would be fine to provide an attribute that names a geopotential surface; that is a well-defined geophysical concept. If it useful, we could provide an attribute to specify the vertical offset wrt a geoid. Following up what you suggested before, we could also have standard names for height and depth wrt a geopotential surface, but I think that any quantity which used such a name would be required to have a grid_mapping which identified the geopotential surface, otherwise it wouldn't be well-defined. Jonathan

[jonathan]

Following a lot of research and a phone conversation that Rich and I have had, I now propose two new grid_mapping attributes in Appendix F, both of type S (string). The first is geoid_name, as originally proposed, described as "The name of the estimate or model of the geoid being used as a datum, e.g. GEOID12B. Corresponds to an OGC WKT VERT_DATUM name. The geoid is the surface of constant geopotential that the ocean would follow if it were at rest." The second attribute is geopotential_surface_name, described as "The name of an estimated surface of constant geopotential being used as a datum, e.g. NAVD88. Such a surface is called an equipotential surface in geodesy. Corresponds to an OGC WKT VERT_DATUM name."

I will open another ticket about how to identify the standard_name of the vertical coordinate which is computed from the formula used by a dimensionless vertical coordinate variable. This is a related issue. To do that, we will need some new standard_names referring to geopotential surfaces, e.g. depth_below_geopotential_surface. (We already have depth_below_geoid in the table.)

Jonathan

[jonathan]

To make this ticket consistent with ticket 143, which I've just opened, I would like to modify it again. I now propose geopotential_datum_name instead of geopotential_surface_name, because I think the phrase geopotential_datum will make more sense in standard names. This phrase exists in online documents found by Google, including some by NOAA.

Jonathan

[rsignell]

I agree with this change: geopotential_datum_name is better.

[davidhassell]

Hello Jonathan, Rich, et al.,

I've just re-read this ticket from top to bottom, and I support the most recent proposal (geoid_name and geopotential_datum_name).

If I understand correctly, either, none or both of these new attributes could be used in a particular grid mapping variable, is that right? If both are given, does some comment need to be made on consistency, as these properties are in the CF domain (even if their values aren't controlled by CF)?

All the best,

David

[jonathan]

Dear Rich and David

Thanks for your comments and support.

Re David's question. I don't think both should be given. They're alternatives for the vertical datum. Here's a modified proposal for Appendix F to prohibit this.

geoid_name. The name of the estimate or model of the geoid being used as a datum, e.g. GEOID12B. Corresponds to an OGC WKT VERT_DATUM name. The geoid is the surface of constant geopotential that the ocean would follow if it were at rest. This attribute and geopotential_datum_name cannot both be specified.

geopotential_datum_name. "The name of an estimated surface of constant geopotential being used as a datum, e.g. NAVD88. Such a surface is often called an equipotential surface in geodesy. Corresponds to an OGC WKT VERT_DATUM name. This attribute and geoid_name cannot both be specified.

It is fine to specify neither of them. The grid_mapping attributes are generally optional so I don't think we have to comment on that. However, the definitions of standard_names which refer to the geoid or a geopotential datum could draw attention to the possibility of precisely specifying the reference surface by using a grid_mapping attribute. If ticket 143 is agreed, I will make a standard_name proposal on the email list in which this point could be included.

Jonathan

[jonathan]

Since no-one has commented on this proposal for more than three weeks, and sufficient support has been given according to the rules, the discussion is concluded and this change should be made in the next version of CF.

Jonathan