Standard names: tidal_sea_surface_height_above_reference_datum and sea_level_residual

[fmanzano-pde]

Proposer's name Fernando Manzano on behalf of the Copernicus Marine In Situ TAC Sea Level Reprocessed product Team

Date 2023-05-30

Summary New standard names for variables included in the new Copernicus Marine In Situ TAC product: INSITU_GLO_PHY_SSH_DISCRETE_MY_013_053

---

- Term tidal_sea_surface_height_above_reference_datum

- Description "Sea surface height" is a time-varying quantity. "Height_above_X" means the vertical distance above the named surface X, in this case above an arbitrary reference datum. The altitude of the datum should be provided in a variable with standard name water_surface_reference_datum_altitude. The tidal component of sea surface height describes the predicted variability of the sea surface due to astronomic forcing (chiefly lunar and solar cycles) and shallow water resonance of tidal components; for example as generated based on harmonic analysis, or resulting from the application of harmonic tidal series as boundary conditions to a numerical tidal model.

- Units m

_Clarification: We cannot use already existing  tidal_sea_surface_height_above_mean_sea_level or tidal_sea_surface_height_above_lowest_astronomical_tide because these two refer to a specific datum (mean sea level or lowest astronomical tide), not to an arbitrary datum that at this stage, for the Copernicus Marine In Situ TAC Sea Level Reprocessed product, will be the reference or datum used for the tide gauge measurements (dependent on the provider). The new name "tidal_sea_surface_height_above_reference_datum" is coherent with the "water_surface_height_above_referencedatum" standard name in this product.

---

- Term sea_level_residual

- Description "Sea level residual" is a time-varying quantity, obtained by discarding the tidal component from sea surface height. The tidal component of sea surface height describes the predicted variability of the sea surface due to astronomic forcing (chiefly lunar and solar cycles) and shallow water resonance of tidal components; for example as generated based on harmonic analysis, or resulting from the application of harmonic tidal series as boundary conditions to a numerical tidal model.

- Units m

[github-actions[bot]]

Thank you for your proposal. These terms will be added to the cfeditor (http://cfeditor.ceda.ac.uk/proposals/1) shortly. Your proposal will then be reviewed and commented on by the community and Standard Names moderator.

[fmanzano-pde]

I know I'm talking with a bot, but I forgot to add that this requirement is kind of urgent as the new product is delivered in November but documentation is delivered in June. Thank you for your understanding.

[taylor13]

Without any special knowledge in this area, I have the following questions:

1. Is the time-mean of the tidal component of sea surface height invariably zero? (From the description, it seems like it should be.) If so, why is specification of the datum of any interest? Would the names tidal_sea_surface_height or tidal_component_of_sea_surface_height be better options? To use this quantity scientifically, wouldn't you just subtract out any time-mean if it weren't already zero? You wouldn't have to know how the mean was introduced.
2. Can we come up with something more specific for sea_surface_residual? Isn't this particular residual the sea_surface_height obtained after filtering out the tidal component? Shouldn't it be similar to non_tidal_elevation_of_sea_surface_height (for which the description says "The phrase non_tidal_elevation describes the contribution to sea surface height variability made by processes other than astronomic forcing of the ocean and shallow water resonance of tidal components.")

I think we should try to avoid inconsistent usage of the the terms height and "elevation". I think "elevation" is commonly (outside of CF) considered to be the same as the CF variables surface_altitude or perhaps ground_level_altitude (although ground level may not be the surface because of overlying snow or ice or vegetation). And "sea_surface_height" is currently defined as "above some reference": "above_geoid", "above_reference_ellipsoid", "above_mean_sea_level", or "above_geopotential_datum",

Could the existing CF term non_tidal_elevation_of_sea_surface_height been just as appropriately named non_tidal_sea_surface_altitude? The phrase 'elevation of (sea) surface height" seems almost redundant, given the common definition of "elevation" and the CF definition of "surface height". Instead of the proposed sea_surface_residual, would non_tidal_sea_surface_height_above_geoid or non_tidal_sea_surface_height_above_geopotential_datum be better?

I also don't know if there would be any difference (over the ocean) between "surface_altitude" and "sea_surface_height_above_geoid". Does someone know?

[fmanzano-pde]

Dear @taylor13

Regarding the second standard name required, to be honest, I didn't realize there was a non_tidal_elevation_of_sea_surface_height standard name that actually fits perfectly for our purposes. Please accept my apologies for this misunderstanding. I have crossed out that part of the original request.

Concerning the first part, I prefer an expert answers.

All the best, Fer

[bperezgomez]

Dear @taylor13

many thanks for your quick response. I also agree with your comments on point 2 (sea_surface_residual not necessary).

With respect to question 1: in fact, all existing related standard names refer to a specific datum:

• tidal_sea_surface_heightabovelowest_astronomical_tide
• tidal_sea_surface_heightabovemean_higher_high_water
• tidal_sea_surface_heightabovemean_lower_low_water
• tidal_sea_surface_heightabovemean_low_water_springs
• tidal_sea_surface_heightabovemean_sea_level

The mean sea level (zero value) is just one of them. This is so because the tidal component can be typically referred in practice to different datums, as the sea or water surface height measurements from which it is obtained. It can be any of those listed here, or even other references not mentioned (e.g.: harbour datum, ellipsoid, etc). Our proposal (reference_datum) is more generic. We choose this generic approach for coherence with the original sea surface height values measured by the tide gauges (our variable SLEV in the Copernicus Marine Service In Situ TAC), from which the tidal component is obtained. The proposed name tidal_sea_surface_height_above_reference_datum would solve this situation for good.

Finally I consider the discussion about the use of "height"/"elevation"/"altitude" relevant, and agree there seems to be some redundancy on this use. However, we would appreciate this to be kept outside the urgent need we have to define these variables for the Copernicus Marine Service In Situ TAC, as it will involve many other groups.

All the best and thank you in advance, Begoña  

[larsbarring]

For the suggested standard name tidal_sea_surface_height_above_reference_datum it seems relevant to have a mechanism to specify which reference datum is used in different datasets. Do you already have any ideas/suggestions for how this could be done?

[fmanzano-pde]

Dear @larsbarring

Within the Copernicus Marine In Situ TAC, we are including an attribute to specify the datum used. Look at the example below (In Situ TAC NetCDF file snippet):

int SLEV(TIME, DEPTH) ; SLEV:standard_name = "water_surface_height_above_reference_datum" ; SLEV:units = "m" ; SLEV:_FillValue = -2147483647 ; SLEV:add_offset = 0.f ; SLEV:scale_factor = 0.001f ; SLEV:long_name = "Water surface height above a specific datum" ; SLEV:valid_min = -2000 ; SLEV:valid_max = 40000 ; SLEV:comment = " " ; SLEV:coordinates = "TIME LATITUDE LONGITUDE DEPH" ; SLEV:sensor_depth = 0.f ; SLEV:sensor_mount = " " ; SLEV:sensor_orientation = " " ; SLEV:data_mode = "R" ; SLEV:time_sampling = 1.f ; SLEV:sea_level_datum = "Harbour Local Datum" ; SLEV:processing_method = "Average from 0.5s data" ; SLEV:ancillary_variables = "SLEV_QC" ;

Notice that the suggested new standard name tidal_sea_surface_height_above_reference_datum is completely aligned with the existent water_surface_height_above_reference_datum (used in the example).

All the best, Fer

[feggleton]

I have added the first name to the cfeditor now. Thank you, this contains all the phrases from similar names.

[larsbarring]

Dear @fmanzano-pde

Thanks for the clarification, but if I am not mistaken there is a typo in the description of the requested standard name:

The altitude of the datum should be provided in a variable with standard name tidal_sea_surface_height_above_reference_datum.

where the boldface is the same as the requested standard name.

[fmanzano-pde]

Dear @larsbarring

You're right! it's wrong, I'm going to correct it in the original petition.

Done!

All the best, Fer

[ethanrd]

Could tidal_sea_surface_height_above_reference_datum (or water_surface_height_above_reference_datum) ever be used with a standard reference datum?

If so, should there also be options to name the reference datum or to provide the definition using a grid_mapping variable?

Also, could the reference datum defined in water_surface_reference_datum_altitude ever be a datum not related to a water surface datum? I'm just wondering if there should be a more generic reference_datum_altitude that could be used in this and other situations where the datum needs to be defined in a variable.

[larsbarring]

Dear @fmanzano-pde

OK, now the picture begins to emerge. If you read the description of water_surface_reference_datum_altitude carefully two problems arise if I understand what you are aiming at (caveat emptor: I might not because I am not an expert on this subject area):

• The description of this standard name clearly makes a reference back to the 'parent' standard name: " ... 'Water surface reference datum altitude' means the altitude of the arbitrary datum referred to by a quantity with standard name 'water_surface_height_above_reference_datum' ..." (my boldfacing). Thus, you cannot reuse it for your requested standard name.

To solve this you might want to request a new standard name, such as tidal_sea_surface_reference_datum_altitude and then pattern the description as far as possible after water_surface_reference_datum_altitude. But then the second problem remains:

• The description of this standard name clearly states that "Altitude is the (geometric) height above the geoid, which is the reference geopotential surface. The geoid is similar to mean sea level. ..." If I understand you correctly this is exactly what you want to avoid by having many different local reference datums.

In your example, SLEV:sea_level_datum = "Harbour Local Datum", is "Harbour Local Datum" a generic reference to a local datum in any harbour, or is the individual harbours intended to be specified by name (or otherwise)?

[fmanzano-pde]

Dear all,

First of all, I'd like to thank you all for this discussion, it's being tremendously interesting and clarifying. Hopefully, the conclusion will be CF aligned, useful, coherent and clear.

I'd appreciate the discussion is limited to the specific requirement raised up. I agree there're more issues related, but, in my opinion, they should be faced apart in a different thread. As I said in my previous messages, it's kind of urgent for us as we have to deliver product specification documents, and it would be great if the final standard names are set.

It's true that I can't reuse the already defined water_surface_reference_datum_altitude as it refers specifically to the water_surface_height_above_reference_datum. In addition, as you've pointed out, this water_surface_reference_datum_altitude (or tidal_sea_surface_reference_datum_altitude) is referencing the geoid. At the moment, we are not sure about how to deal with this. In fact, as you can see in the example I provided, we are only mentioning the datum used (text string). "Harbour Local Datum" is not a generic reference, it's specific of any harbour. More details about this datum can be found in the free-text attributes, which we use to extend the information about the dataset. Other possible values of sea_level_datum are "Ordnance Datum Malin Head", "Malin Head OSGM15 Ordnance Datum", "Chart Datum", "Harbour Local Datum", "Geodetic Datum", "Admiralty Chart Datum". These are examples of the "datums" used by the providers. The idea is reporting about the datum as a reference, but not as a quantity in metres. For sure, it would be great if all these references are harmonized in the future (@bperezgomez told me that's a very well known issue raised at global level for all tidegauge networks)

---

Then, I change my original proposal to 🍎

A single standard name tidal_sea_surface_height_above_reference_datum, but changing the description as:

"Sea surface height" is a time-varying quantity. "Height_above_X" means the vertical distance above the named surface X, in this case above an arbitrary reference datum. The altitude of the datum could be provided in a specific variable. Other mechanisms to extend the information about the datum are also allowed. The tidal component of sea surface height describes the predicted variability of the sea surface due to astronomic forcing (chiefly lunar and solar cycles) and shallow water resonance of tidal components; for example as generated based on harmonic analysis, or resulting from the application of harmonic tidal series as boundary conditions to a numerical tidal model.

---

If you agree on this, I'll change the original request as aforementioned. Then, I support the idea of opening a new thread to get things in order regarding the datum (water_surface_reference_datum_altitude and, maybe, tidal_sea_surface_reference_datum_altitude).

All the best, Fer

PS This reply has been discussed with @bperezgomez

[larsbarring]

Dear @fmanzano-pde and @bperezgomez,

I think that usually we avoid introducing this kind of unspecific alternatives in the description (definition) of standard names. But here are some thoughts (same caveat emptor as above) that might help:

The underlying problem is that you cannot uniquely specify a generally valid reference datum. This could possibly be handled by more clearly indicate this in the standard name:

tidal_sea_surface_heightabove**local_reference_datum**

That has the following description (simple alternative):

Sea surface height" is a time-varying quantity. "Height_above_X" means the vertical distance above the named surface X, in this case above an arbitrary reference datum. The local datum should be identified by name in the attribute local_datum_identifier. The tidal component of sea surface height describes the predicted variability of the sea surface due to astronomic forcing (chiefly lunar and solar cycles) and shallow water resonance of tidal components; for example as generated based on harmonic analysis, or resulting from the application of harmonic tidal series as boundary conditions to a numerical tidal model.

or (more elaborate alternative):

Sea surface height" is a time-varying quantity. "Height_above_X" means the vertical distance above the named surface X, in this case above an arbitrary reference datum. The local datum should be specified in a separate variable having the standard name local_datum_identifier. The tidal component of sea surface height describes the predicted variability of the sea surface due to astronomic forcing (chiefly lunar and solar cycles) and shallow water resonance of tidal components; for example as generated based on harmonic analysis, or resulting from the application of harmonic tidal series as boundary conditions to a numerical tidal model.

The latter more elaborate alternative requires the new standard name local_datum_identifier, what will give details about name (required) , reference to an authoritative document/publication, possibly geographic location (lat/lon), height above geoid if available, ...

These are just some thoughts, and I think that it is essential to have these scrutinized by experts on standard names and CF @feggleton @japamment @davidhassell @JonathanGregory

[taylor13]

As I understand it, the proposed quantity is a relative measure of vertical distance, which often cannot be translated into an "absolute" altitude. I wouldn't include "above_reference_datum" in the standard name unless the altitude of the reference datum were required (or strongly recommended). I think the description under the current standard name water_surface_reference_datum_altitude could be modified so that this variable could serve as a reference both for water_surface_height_above_reference_datum and your new standard_name.

If an absolute altitude cannot be determined, would the standard_name "relative_height_of_tidal_sea_surface" be an acceptable alternative? Of course, one would wonder "relative to what?", but that apparently is not known for sure.

If you want to define a local_datum_identifier, I think a controlled vocabulary would be needed listing the options. Above you listed: "Ordnance Datum Malin Head", "Malin Head OSGM15 Ordnance Datum", "Chart Datum", "Harbour Local Datum", "Geodetic Datum", "Admiralty Chart Datum". Is this a complete list? Could other identifiers be needed in the future? Perhaps you could include this attribute in your files without CF's endorsement. (For the huge CMIP project involving datasets generated by 100's of models, we include lots of useful attributes that are not mentioned by the CF conventions. I think CF should limit its scope to attributes needed to serve broad needs.)

[fmanzano-pde]

Thank you very much for your comments.

I totally agree with @taylor13. In my opinion, talking about specific attributes is out of the scope. Our _SLEV:sea_leveldatum attribute is defined in the scope of the EuroGOOS Tide Gauge Task Team, specifically in the document NetCDF Recommendations for Copernicus Marine

I support the redefinition of water_surface_reference_datum_altitude to detach it from water_surface_height_above_reference_datum. It would be fine just removing "referred to by a quantity with standard name 'water_surface_height_above_reference_datum'". Thus, backward compatibility would be maintained.

I don't like the addition of "local" proposed by @larsbarring because it's breaking the coherence with the other related standard name already suffixed as *_above_reference_datum. In addition, it does not add much.

On the other hand, regarding the new standard_name related with the datum local_datum_identifier, I think it's not the best time to add a new standard_name when it's still not clear how this is going to be implemented; experts are still in the definition process.

---

In conclusion, to minimize the impact and fulfill our current and urgent needs, I propose to add the original suggested standard_name tidal_sea_surface_height_above_reference_datum which is necessary and compatible with what already exists.

And I'd remove the controversial part of the definition, resulting: "Sea surface height" is a time-varying quantity. "Height_above_X" means the vertical distance above the named surface X, in this case above an arbitrary reference datum. The tidal component of sea surface height describes the predicted variability of the sea surface due to astronomic forcing (chiefly lunar and solar cycles) and shallow water resonance of tidal components; for example as generated based on harmonic analysis, or resulting from the application of harmonic tidal series as boundary conditions to a numerical tidal model.

That way, above_reference_datum is coherent with water_surface_height_above_reference_datum and the definition is also coherent with the tidal_sea_surface_height_above standard names.

_By the way, I'm planning to open a new thread in CF Conventions to discuss what in my opinion is an incongruity between the standard name definition of standard name given by CF Conventions and the standard names created in practice. As far as I understand, the standard name defines the physical quantity but no the estimators (or the references). For instance, I think there are too tidal_sea_surfaceheight standard names. The "physical quantity" is the same but referenced to different references (forgive the redundancy). I probably am wrong, but I think it is worth clafifying.

All the best, Fer

[larsbarring]

I don't like the addition of "local" proposed by @larsbarring because it's breaking the coherence with the other related standard name already suffixed as *_above_reference_datum. In addition, it does not add much.

Breaking the coherence to other related standard names was intentional. The reason is that all the other related standard names refer to a specific reference datum that can be applied everywhere. Here we have a different situation where there are many different reference datums (such as "Harbour Local Datum"). The intention was exactly to signal that this standard name refers to a quantity that in some parts is fundamentally different from the other related standard names/quantities.

Regarding the other parts I have nothing to add; my suggestions were nothing more that suggestions/food for thought. With this I think that I have said all that might want to say.

Kind regards, Lars

[fmanzano-pde]

Dear @larsbarring,

I'm very sorry as I clearly misunderstood your suggestion. It's true the standard name you suggested is coherent with the other tidal_sea_surface_height_above standard names, all of them referred to specific datums. Please, accept my apologies.

Nevertheless, in my opinion, this consideration leads into another inconsistency in terms of the tidal_sea_surface_height_above standard names (referred to specific references) and water_surface_height_above_reference_datum (referred to a "generic" datum).

Within the Copernicus Marine In Situ TAC, we need to provide both variables tidal_sea_surface_height_above_reference[_local]_datum and water_sea_surface_height_above_reference_datum in the same file, and both referred to the same datum. It's quite weird for me having different suffixes for the same thing.

In conclusion, I'm still in favor of creating this new tidal_sea_surface_height_above_reference_datum.

All the best, Fer

[JonathanGregory]

Dear Fer @fmanzano-pde et al.

Thanks for this careful and interesting discussion. Am I correct in understanding that the reference datum Fer wants, for both tidal SSH and water SSH, is a local datum (as Lars says), and not a 2D surface which is defined everywhere, like mean_sea_level, lowest_astronomical_tide, as so on? That is, it's an arbitrary benchmark. If it's local, is the benchmark attached to the land, or is it an altitude, which would be referred to the geoid (which it itself a 2D surface defined everywhere)?

Best wishes

Jonathan

[bperezgomez]

Dear @JonathanGregory and all,

I also find this discussion very interesting and convenient, thank you so much for joining the thread. Very much needed.

The basic idea behind this request raised by @fmanzano-pde for the Copernicus Marine Service In Situ TAC is to allow for integration of tide gauge data with heterogeneous datum information, depending on the agency or data provider.

This may be a 2D surface (e.g.: lowest astronomical tide or chart datum, defined at national level) or not. It will depend on the station/institution. And yes, some stations may provide only "local datums", not linked to a 2D surface but to a land "bench mark".

The standard name we are looking for should allow this heterogeneity, if possible, at least at this stage of the product development in Copernicus. On the other hand, we must ensure we provide final users with the required metadata information related to this datum, in the most convenient way, when available (through existing and agreed attributes).

In summary, we are looking for a standard name that refers to a "generic" datum, not to a pre-defined datum, and coherent with the one used for total sea level in Copernicus Marine Service In Situ TAC at this moment (tide and water level would be referred to the same datum in this product).

So going back to @fmanzano-pde proposal, I think it fulfills the above mentioned requirements, do you agree?:

• Standard name: _tidal_sea_surface_height_above_referencedatum

• Definition: _"Sea surface height" is a time-varying quantity. "Height_aboveX" means the vertical distance above the named surface X, in this case above an arbitrary reference datum. The tidal component of sea surface height describes the predicted variability of the sea surface due to astronomic forcing (chiefly lunar and solar cycles) and shallow water resonance of tidal components; for example as generated based on harmonic analysis, or resulting from the application of harmonic tidal series as boundary conditions to a numerical tidal model.

Thank you in advance and kind regards, Begoña

[taylor13]

Given the non-standardized "reference_datum" for tidal height, I would prefer the standard_name "relative_height_of_sea_surface_due_to_tides", to distinguish this variable from a variable measured relative to a known "reference datum". I think that knowing the reference height would be of little use in practice. If the actual height of the non-tidal component of sea surface height were known, then couldn't the actual sea surface height as a function of time be calculated as H(non-tidal) + H(tidal) - <H(tidal)>, where <H> indicates the time-mean value of H over the reporting period?

[JonathanGregory]

If there's a use-case for reporting actual SSH wrt an arbitrary local datum, CF ought to support it. I understand Karl's view that differences seem more meaningful, but the actual values are not really "relative" SSH, which is likely to be understood as wrt land, since that's what "relative sea level change" means. I think tidal_sea_surface_height_above_reference_datum is OK, but the definition should say more about what datum means in this case. For example

The reference datum could be a geophysical surface, a height with respect to a geophysical surface, or a local benchmark attached to the land. Because the definition of the datum may vary from one place to another, spatial differences in actual tidal_sea_surface_height_above_reference_datum are not generally physically meaningful. However, local differences in this quantity over time are physically meaningful.

Is that correct?

[taylor13]

I understand Jonathan's point and also wasn't aware of the usual meaning of "relative sea level change", so I retract my stated preference and support adoption of tidal_sea_surface_height_above_reference_datum with a clear explanation of "reference_datum" along the lines suggested above.

[drapm]

Hi all,

Begoña has suggested I join in the discussion, as I'm part of a data centre distributing sea level data - PSMSL, and we've been struggling to find a suitable CF name for data from tide gauges. The discussion above has been very helpful.

On Fer's proposal - I'd also support tidal_sea_surface_height_above_reference_datum. I think there's a need for an accompanying name for observations too - water_surface_height_above_reference_datum is ideal for that if we're able to drop that requirement for an explicit link to the geoid. That's not a known value for tide gauges - you can estimate it if you've got a permanent GNSS receiver installed nearby, but it will change with time as the land rises or falls.

On @taylor13 's suggestions for information about the reference datum, at most locations that will be a fixed distance below a selected benchmark on stable ground - we could provide that distance and a description of that benchmark. The fixed distance is sometimes chosen so it coincides with a named reference datum. There are some controlled vocabularies listing these - https://epsg.org/home.html is a widely used by industry, and more recently the IAG have worked with the ISO to develop the ISO Geodetic Registry.

To confuse things further, there's also historical records where we don't have any information about the reference datum.

Best regards, Andy Matthews

[fmanzano-pde]

Dear Andy and Jonathan,

thank you very much for participating in the discussion, you are more than welcome.

I feel we finally reach an agreement, although it is worth it to wait a little bit more. This would be the suggestion to be accepted:

---

- Term tidal_sea_surface_height_above_reference_datum

- Description "Sea surface height" is a time-varying quantity. "Height_above_X" means the vertical distance above the named surface X, in this case above an arbitrary reference datum. The tidal component of sea surface height describes the predicted variability of the sea surface due to astronomic forcing (chiefly lunar and solar cycles) and shallow water resonance of tidal components; for example as generated based on harmonic analysis, or resulting from the application of harmonic tidal series as boundary conditions to a numerical tidal model. The reference datum could be a geophysical surface, a height with respect to a geophysical surface, or a local benchmark attached to the land. Because the definition of the datum may vary from one place to another, spatial differences in actual tidal_sea_surface_height_above_reference_datum are not generally physically meaningful. However, local differences in this quantity over time are physically meaningful.

---

_In addition, I'd propose modifying the definition of the term water_surface_height_above_reference_datum to be aligned with the new term, keeping the compatibility with what is already defined (changes in bold):_

'Water surface height above reference datum' means the height of the upper surface of a body of liquid water, such as sea, lake or river, above an arbitrary reference datum. The altitude of the datum could be provided in a variable with standard name water_surface_reference_datum_altitude. The surface called "surface" means the lower boundary of the atmosphere. Nevertheless, the reference datum could be a geophysical surface, a height with respect to a geophysical surface, or a local benchmark attached to the land. Because the definition of the datum may vary from one place to another, spatial differences in actual tidal_sea_surface_height_above_reference_datum are not generally physically meaningful. However, local differences in this quantity over time are physically meaningful.

Thank you very much!

All the best, Fer

[JonathanGregory]

That looks fine to me, thanks Fer @fmanzano-pde

[github-actions[bot]]

This issue has had no activity in the last 30 days. Accordingly:

• If you proposed this issue or have contributed to the discussion, please reply to any outstanding concerns.
• If there has been little or no discussion, please comment on this issue, to assist with reaching a decision.
• If the proposal seems to have come to a consensus, please wait for the moderators to take the next steps towards acceptance.

Standard name moderators are also reminded to review @feggleton @japamment

[feggleton]

I don't have anything to comment on this discussion, I think it looks fine and have updated the cfeditor to reflect the latest update. I would like @japamment to take a look at the wording to make sure she's happy before accepted.

I will also add the change to the existing term to the cfeditor. Thanks

[feggleton]

I should note there is also the existing term water_surface_reference_datum_altitude in case this also needs to be amended.

[fmanzano-pde]

I should note there is also the existing term water_surface_reference_datum_altitude in case this also needs to be amended.

Thank you very much, Fran. As you rightly said, water_surface_reference_datum_altitude is linked and relevant. In fact, it came up several times during this thread. Nevertheless, it was decided to treat it as a separate issue in the future, because it requires further discussion.