Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Describe Tidal Datums through grid mappings or directly with reference epochs #79

Open
ethanrd opened this issue Oct 12, 2020 · 7 comments

Comments

@ethanrd
Copy link
Member

ethanrd commented Oct 12, 2020

The two standard names suggested in issue cf-convention/vocabularies#74 (tidal_sea_surface_height_above_*) introduce the phrases “_above_mean_lower_low_water” and “_above_mean_higher_high_water”. Further discussion indicated a need for a reference epoch to further specify Mean Lower Low Water (MLLW) and Mean Higher High Water (MHHW). Issue cf-convention/vocabularies#188 further discusses, generalizes, and agrees on a definition for a reference epoch standard name.

In my comment in issue cf-convention/vocabularies#188, I suggest that CF grid mapping (CRS) is an appropriate location to further specify/define tidal datum given it already supports specifying other vertical datums (geoid and reference ellipsoid).

@JonathanGregory gives a counter argument that tidal datums are dissimilar enough to geodetic datums that they belong in a separate location.

So, I think the decision for this Issue is whether information that further specifies or defines a tidal datum belongs in a grid_mapping variable or in a separate location (e.g., directly with a reference epoch). To get there, I think we need to discuss the role (or generality?) of grid mappings and the role of tidal datums (and how they compare to geodetic datums).

@davidhassell
Copy link
Collaborator

Hi @ethanrd,

In the tidal data epoch description issue I wrote:

my first thought is that storing the reference ellipsoid (say) in a grid mapping is in fact not the right place afterall, because the grid mapping is only for datums of the horizontal and vertical coordinates, not the data, such as sea_surface_height_above_reference_ellipsoid.

I can see why this caused confusion, sorry.

What I was trying to say was that when a sea_surface_height_above_reference_ellipsoid variable is a data variable then its values are not acting as coordinates to another a data variable, and so are not part of the coordinate reference system described by the grid mapping variable. Thus the neither the reference baseline to the data variable, nor its metadata (e.g. epoch), should not be stored in the grid mapping, because the reference does not comprise a coordinate datum.

That, at least, I is how I think things stand right now. How does that sound?

Thanks,
David

@JonathanGregory
Copy link
Contributor

Dear @ethanrd et al.

Tidal datums such as "mean lower low water" or "lowest astronomical tide" are geophysically defined surfaces. In that respect that are like the sea floor, mean sea level, the geoid and the sea surface, and generally similar to other geophysically defined surfaces mentioned in standard names, such as cloud top, convective cloud base, tropopause and ground level. All of these geophysically defined surfaces are used to specify the level for other quantities e.g. air_temperature_at_cloud_top, sea_water_potential_temperature_at_sea_floor. Those geophysical surfaces which are sharply localised in the vertical direction are useful as the reference height for vertical coordinates e.g. sea_surface_height_above_geoid, height_above_sea_floor, and plain height (which is above "the surface" i.e. bottom of the atmosphere). The existing standard names tidal_sea_surface_height_above_lowest_astronomical_tide and tidal_sea_surface_height_above_mean_sea_level are of this kind; they use a geophysically defined surface as a vertical datum.

There are not many of these surfaces, and I think it's perfectly fine to identify them by name in the standard name. There are only a handful of tidal datums, and if we have standard names for tidal heights and a few other quantities wrt each datum, that wouldn't be many. I don't think we need a more general approach.

The reference ellipsoid is not a geophysically defined surface, but a geodetic construction. It is the reference surface for geodetic height, latitude and longitude. None of the geophysically defined surfaces could be used for this geodetic purpose because they are not constant, precise or simple, like the reference ellipsoid is. It needs a couple of numbers to define it, and there's an infinite number of possible choices. By contrast, there is only a small number of geophysical surfaces, but each of them needs to be described by an entire field of data, and some of them are time-dependent as well.

In summary, I think tidal datums are quite different from geodetic datums, and we don't need the same approach.

Cheers

Jonathan

@ethanrd
Copy link
Member Author

ethanrd commented Oct 14, 2020

Hi @davidhassell,

Are there times when a sea_surface_height_above_reference_ellipsoid variable might be used as a coordinate variable? I had assumed that sea_surface_height_above_reference_ellipsoid variables were always data variables. Similar to 500 mb geopotential height or geopotential_height_at_cloud_top, it defines a surface of interest relative to some vertical datum at a given time (or evolving over time).

While these data variables don’t need an explicit vertical coordinate variable, the vertical component of the data variable’s CRS, I believe, is still there. Yes, the CRS is used as a reference for the data rather than defining the location of the data but isn’t it still the same CRS? And if so, it seems overly complex to have two places for CRS information when one might suffice.

Perhaps we should organize a call to discuss further. Preferably with someone who really understands CRSs and datums. (Everytime I think I’m starting to understand CRS and datums, I end up instead finding out how little I actually understand.)

Cheers,
Ethan

@ethanrd
Copy link
Member Author

ethanrd commented Oct 14, 2020

Hi @JonathanGregory, all,

My understanding is that whether a vertical datum is based on a reference ellipsoid, a geoid, a survey marker, or calculations from local tide levels (e.g., “mean lower low water”), the role of a vertical datum is to be a reference point from which to measure heights and depths.

Currently, sea_surface_height_above_reference_ellipsoid, sea_surface_height_above_geoid, and sea_surface_height_above_geopotential_datum can all reference a grid mapping variable to name or define the reference ellipsoid, geoid, or geopotential datum being used as the reference level.
For the proposed standard names sea_surface_height_above_mean_lower_low_water and sea_surface_height_above_mean_higher_high_water, MLLW and MHHW play the same role as reference ellipsoid, geoid, and geopotential datum in the above standard names. If I have that right, then a grid mapping variable seems like the appropriate place to name, define, or provide information that further specifies how the MLLW and MHHW are calculated.

Cheers,
Ethan

@ethanrd
Copy link
Member Author

ethanrd commented Oct 14, 2020

Oops, the new standard names are tidal_sea_surface_height_above_{MLLW|MHHW}, I dropped the tidal_ prefix in my above comment.

@JonathanGregory
Copy link
Contributor

Dear @ethanrd

I fear I'm just about to repeat myself! I think that a tidal datum and a geodetic datum are similar in that they use the word "datum" and they refer to a level, but otherwise they're rather different. I may be wrong, but I do not believe that a tidal datum would be used in a coordinate reference system. When things are located above "mean sea level", it doesn't literally mean it. As I said before, I believe it means wrt a reference ellipsoid, which is chosen as a local approximation to the geoid, which itself is quite similar to mean sea level.

The grid mapping is about projections and coordinate reference systems, which are simple but very precise things. It's true that we also have a way to name the geoid in the grid mapping. The geoid is not defined, but measured. The many "geoids" which are available are all different estimates of the same geophysical surface (or they differ from one another by the choice of geopotential). They have been given names to distinguish them because each is a dataset, and that name can be recorded in the grid mapping as metadata for quantities which refer to the geoid e.g. sea_surface_height_above_geoid and altitude.

I agree with you that it would be analogous to record in the grid mapping variable any further name or information which indicated which estimate of mean lower low water or lowest astronomical tide was being used, for instance. Is that what is being suggested? Although it's analogous, I'm not sure it's a good idea. I'm not convinced that tidal datums belong in the grid mapping at all, if they are not relevant to geodesy.

Probably I misunderstood. My point is that those two tidal datums are different geophysical variables from each other and from mean sea level. "Tidal datum" is not a single geophysical quantity, but a class of things which includes those three. Specifying which tidal datum you mean is not like specifying which geoid you're using.

Best wishes

Jonathan

@ethanrd
Copy link
Member Author

ethanrd commented Oct 21, 2020

Hi @JonathanGregory,

I agree that tidal datum and geodetic datum are different in many ways. I think where we disagree is in whether those differences mean that tidal datum shouldn’t be used in a coordinate reference system.

I believe that whether based on a reference ellipsoid, a geoid, a regional vertical datum (e.g., NAVD88 and ODN), a survey benchmark, or a tidal datum, if it is used as the zero level for the vertical coordinate then it should be included in (and is an essential component of) the coordinate reference system and, in CF, the grid mapping variable.

Anyway, I'm pretty sure that what I know about CRSs and vertical datums is just enough to be dangerous. It might be good to get a few other voices in on this discussion. I think @dblodgett-usgs was in on the discussion that expanded grid mappings to be more explicit about how it relates to CRS. Anyone else we might ping?

Cheers,

Ethan

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants