[ocefpaf]

After a whole day banging my head against the wall to figure out why a sea surface filter I created was removing my z coord I realized we made a mistake in the standard_name for the derived z coord in ocean models. (See #509 and my reckless copying-and-pasting after that!)

This PR changes sea_surface_height_above_reference_ellipsoid to altitude. From the CF-1.6 document:

Altitude is the (geometric) height above the geoid, which is the reference geopotential surface. The geoid is similar to mean sea level.

PS: -z is altitude 😉

[ocefpaf]

Pinging @rhattersley.

Let me know if there is anything else I need to do in this PR

[pelson]

👍 - though I have 0 knowledge of this part of the codebase.

[rhattersley]

The CF spec for something like ocean sigma over z defines the derived coordinate as "height, positive upwards, relative to ocean datum (e.g. mean sea level)". I note the use of the vague term "ocean datum" and "e.g." which implies the ability to use any well defined vertical datum. So even with complete CF compliance the standard name of the derived coordinate is not limited to a single value. (It might not even have a standard name!) But the source coordinates such as eta and depth are also defined relative to the ocean datum, so we could check which standard name/datum they are using. In the case of ocean sigma over z it looks like the derived coordinate should have the same standard name as eta. Is that true?

[ocefpaf]

In the case of ocean sigma over z it looks like the derived coordinate should have the same standard name as eta. Is that true?

That is not OK for me. I interpret eta as Sea Surface Height (SSH is a 2D variable or, if varying in time, 3D) and not the model grid z cooridnate.

Pinging @rsignell-usgs to help interpret the CF-conventions (or maybe we should call a lawyer?)

[rsignell-usgs]

I was just talking to Jonathan Gregory about this. The CF documentation is very vague on the calculation of dimensionless vertical coordinates. We agreed that we need a way to say that the output of the calculated vertical coordinate is "height_above_geopotential_surface" and then be able to specify that this geopotential surface is something like NAVD88 or ODN. @ocefpaf is correct that the water level and water depth variable are not coordinates, but since those variables are the only way to get the units of the computed vertical coordinate, that's where they come from in the computation of z.

[rsignell-usgs]

Because standard_name is already taken by the type of vertical coordinate (e.g. ocean_sigma_coordinate) , maybe we need something like vertical_coordinate_standard_name or something. @JonathanGregory, can you correct me here?

[JonathanGregory]

That's right. I will propose a new attribute on a CF ticket. I was thinking of making it sound more general such as result_standard_name (meaning the result of the formula) in case there is a need for something like that elsewhere. Jonathan

[JonathanGregory]

By the way, I agree with Richard's interpretation. The standard_name of the result is implied in some cases (like this one) by the standard_name of one or more of the formula terms. However, this is not always so; sometimes the formula implies a particular standard name. Saying what it should be is redundant, but would be much easier for some purposes, I expect, and it could also be specified how it can be checked to avoid inconsistency. This need some clarification in every case in Appendix D, so it's a bit of work, but would be useful, I think. Anyway, this should be the subject of the CF ticket. Jonathan

[rhattersley]

That is not OK for me. I interpret eta as Sea Surface Height (SSH is a 2D variable or, if varying in time, 3D) and not the model grid z cooridnate.

That makes sense - I over simplified in haste. They're both the height of something relative to the same datum, but one is explicitly the height of the sea surface and the other is the height of the phenomenon. They will have different standard names.

So in the absence of any extensions to CF, how about a map from eta name to derived coordinate name? For example:

eta	derived coordinate
sea_surface_height_above_geoid	altitude
sea_surface_height_above_reference_ellipsoid	height_above_reference_ellipsoid

We'd also want to include the aliases.

[ocefpaf]

So in the absence of any extensions to CF, how about a map from eta name to derived coordinate name?

Better than what we have now. I will change this PR to reflect that.

[ocefpaf]

Here are all possible eta names I could find. I added some derived z-coord name suggestions:

derived_names = dict(
    sea_surface_elevation='elevation',
    sea_surface_height='height',
    sea_surface_height_above_geoid='altitude',  # or 'height_above_geoid' ?
    sea_surface_height_above_reference_ellipsoid='height_above_reference_ellipsoid',
    sea_surface_height_above_sea_level='height_above_sea_level',
    water_surface_height_above_reference_datum='height_above_reference_datum'
    )

After some thinking I have to say that I do not like this extra complexity. I think that calling all the derived z-coord altitude (or height) is better. The ambiguity, if that is a problem, should be resolved by the user via the eta standard_name.

My problem with this complexity is the difficulty to access the z-coord. Using axis='Z' won't work since, we have more than one z-coord (the non-dimensional and dimensional vertical coordinate)*. So the user must print the cubes, look for what s/he is getting, copy-and-paste the name, and than load the z-coord! That is too cumbersome when dealing with different models.

* In an ideal world axis='X'/'Y'/'Z'/'T' would always return one and only one coord. We have that problem with time and z. I know that this is a CF-bug... But maybe we have a loophole here to make users life a little better when it comes to the z-coord.

What do you think @rsignell-usgs and @rhattersley?

[JonathanGregory]

Dear @rsignell-usgs, @ocefpaf and @rhattersley

Following my conversation with Rich and this discussion, please have a look at the proposal I have made in CF ticket http://cf-trac.llnl.gov/trac/ticket/143.

Jonathan

[JonathanGregory]

By the way, can you tell me if I can request github to copy my own comments back to me by email (for the record)? Thanks.

[rsignell-usgs]

@JonathanGregory , github does not send you notifications of your own changes. So I always go to the top of the e-mail thread and click on the "View it on GitHub" link at the bottom of the 1st notification. By viewing the convervation on github issues instead of in your e-mail you can see your comments and also benefit from the embedded images, code syntax highlighting, etc. Just like on Trac issues.

[ocefpaf]

I am closing this. The CF way will be http://cf-trac.llnl.gov/trac/ticket/143.

For now I will keep using the wrong and awfully long sea_surface_height_above_reference_ellipsoid.

[rsignell-usgs]

Agreed.

[rsignell-usgs]

The CF way: we should encourage the use of sea_surface_height_above_geopotential_datum for standard_name (and the new computed_standard_name for coordinate calculated via formula_terms). And we need to then also specify geopotential_datum_name=NAVD88
as described here: http://cf-trac.llnl.gov/trac/ticket/118