Clarification: Vertical Datum

[marqh]

Hello GRIB experts

please may request some feedback on how to properly implement vertical spatial referencing for GRIB2?

How is the vertical datum defined in GRIB2 for parameter codes which use geometric height, e.g.
0-3-6 Geometric Height
0-6-26 Height of convective cloud base
0-6-27 Height of convective cloud top

Are these vertical height data parameters defined with respect to a defined single vertical datum in all cases?
How is this defined? is it specified within the manual on codes somewhere?

Can the vertical datum reference be specified within a message, for example, to distinguish:

• EGM2008
• WGS84
  vertical datum use?

How would this be distinguished from a height above a local land surface, above ground level; again a different vertical datum?

This is specifically where a height parameter is being stored within the data payload. I believe this is independent of fixed surface definitions, which are handled differently.
Code table 4.5 includes entries

101 Mean sea level
102 Specific altitude above mean sea level m 
103 Specified height level above ground m

but these relate to the definition of the surface, not the defintion of the data payload parameter

many thanks for your help and advice
@marqh
@bjwheltor

[sebvi]

Dear @marqh,

you may want to look at the section 3 and more specifically Code Table 3.2 "Shape of the Earth" used in several templates in that section. You have many options in there and the possibility to propose new options if required.

[marqh]

Hello @sebvi

thank you for the feedback. Our analysis of the Manual suggested to us that the Shape of the Earth definitions in 3.2 only apply to the 2D horizontal position, as defined in section 3 templates.

Code table 3.2 does not define vertical datum definitions, as far as we can see.

More importantly, there is no entry within 3.2 that gives any indication of how mean sea level is interpreted.
There is no mean sea level or equivalent within 3.2. The only shapes are spherical, oblate spheroid, specific WGS84 and a special case of the OSGB1936 datum.
If we were to interpret vertical datum with respect to the WGS84 spheroid at high latitiudes (e.g. 51°) then we see deviations of ~50m compared to mean sea level measurements. Indeed this is a key point for the EGM2008 vertical datum.
This is a really problematic interpretation.
WGS84 is not mean sea level.

Mean sea level is described in 4.5,

101 Mean sea level
102 Specific altitude above mean sea level m

but this is not defined with respect to any entries in code table 3.2

There are no cross references between the height parameters in code table 4.2 and any sense of vertical datum.

I'm really nervous of trying to use the current code table 3.2 for vertical datum definition, this appears to me to bring really significant risk.

code table 4.5 contains the explicit but unreferenced definitions of mean sea level and above ground
Are these accepted definitions that can be used for referencing?
Are these supported by further specification in the manual on codes? Are they related to any geospatial standardisation, or are they defined in a specific meteorological context that the WMO is directly responsible for?

With these in mind, how are the 4.2 entries, including

0-3-6 Geometric Height
0-6-26 Height of convective cloud base
0-6-27 Height of convective cloud top

to be interpreted?
Are these to always be interepreted with respect to a WMO concept: mean sea level , above ground? If so, which one?

Is the manual on codes explicit about this? can we provide references?
Or, is this somehow implicit?

many thanks
marqh

[sebvi]

Hi @marqh

yes the section 3 is in principle to specify grids, but there is no place in GRIB2 to specify vertical datum as far as I am aware.

I thought it would be acceptable to extend code table 3.2 to add vertical datum. Not disregarding horizontal datum but adding entries specifying horizontal datum +vertical datum (current entry 9 in that table defines mean sea level using Newlyn datum). This is the simplest solution I can think off. This is because the definition of the vertical axis is in section 4 mixed with everything else. If we were to add the datum there through a new code table you would need to potentially duplicate all the existing templates to accommodate this! Note that this need for duplication will be nicely solved through template component in GRIB3 since the vertical coordinate will have its own section (but at the moment I don't think we did port the horizontal datum yet, need to check).

Regarding table code table 4.5, I have asked myself as well how mean sea level is exactly defined. I don't think we can prescribe anything a posteriori, it could break existing data assuming a different definition. I am not in favor to add new entries in that table because the table is already quite packed and we are running out of free entries there.

[marqh]

to add to the uncertainty in this realm, i have just been investigating the specification within code table 3.15:
Code table 3.15 – Physical meaning of vertical coordinate
which includes entries for

102 Altitude above mean sea level  m 
103 Height above ground (see Note 1) m

however, the use of code table 3.15 is limited to only a small number of section 3 templates:

3.1000 – cross-section grid with points equally spaced on the horizontal
3.1200 – time section grid

so this code table is only able to be used within these 2 very specific limited scope templates, and not widely applicable.

[marqh]

An option that we can explore to add new code table entries to
4.2 code tables with unambiguous definitions, providing new code table entries that make this distinction clear, using terminology consistent with definitions in 4.5
mean sea level and ground level are used in 4.5 as controlled terms, indicating specific vertical datum definitions.

This approach would be additive in code table entries and not involve the management of cross referencing between code table 4.2 and 3.2, which may be difficult to specify and enforce.

e.g.

Product discipline 0 –   Meteorological products, parameter category 3: mass
Geometric altitude above mean sea level m
Geometric height above ground level m

There may be a number of 4.2 sub-tables where such specialisation could be useful, e.g.

0-6-26 Height of convective cloud base
0-6-27 Height of convective cloud top

could benefit from new entries

Geometric altitude above mean sea level of convective cloud base m
Geometric height above ground level of convective cloud base m
Geometric altitude above mean sea level of convective cloud top m
Geometric height above ground level of convective cloud top m

Analysis would be required to ascertain whether there are further ambiguous entries.

In this case, we may consider adding to the Manual definitions pages (21 of 1180) to include explicit definitions of these controlled terms, already in widespread use in 4.5

I think this is a viable alternative that is worth considering alongside the option to extend 3.2 shape of the earth and manage implicit referencing between sections 3&4 for some 4.2 and 4.5 entries.

[marqh]

@efucile @jitsukoh

Jitsuko, Enrico:

please may I request that you consider sharing your perspectives on this topic with us on this ticket?

many thanks
Mark

[efucile]

This is due to the poor design of GRIB2. It was designed with the intent to serve NWP models without the need for the precision required in current applications. We have started to work on GRIB3 to make the needed separation between the horizontal and the vertical and allow the required spatial definitions. I don't believe that there is a simple fix for this withing GRIB2 because any change would be major and require a change of major version in GRIB

[marqh]

@efucile many thanks for your comments,

I agree that better vertical datum handling in general within GRIB2 is going to be hard / unfeasible, and that GRIB3 may provide better change potential.

With this in mind, how would you view my alternative proposal? the targeted addition of individual GRIB2 parameter codes in code table 4.2, using the same terminology as used in code table 4.5, for example

Product discipline 0 –   Meteorological products, parameter category 3: mass
Geometric altitude above mean sea level m
Geometric height above ground level m

This would be an interim measure, with perhaps just enough detail to deal with the current challenges that my organisation are trying to address

[etoyoda]

Dear Mark,

Jitsuko invited me to respond.

I'd support adding new entries to code table 4.2, such as "Geometric height above ground," but I think that should be limited to the extent needed for real use case.

The obscurity of the definition of "height" has its origin in GRIB Edition 1. The description of GRIB2 parameter "0-3-6 Geometric height" is almost same to GRIB1 counterpart "8 Geometrical height". Many GRIB1 parameters has counterpart in GRIB2, defined in the first draft of the code form. I don't know the actual discussion in the 1990s among the people now all retired, but apparently they considered compatibility and migration; and unfortunately we have many parameters with unclear definition.

Looking at code table 3.15, we can see the terminology "altitude is above mean sea level, and height is above ground," which is common to Aviation community. But I have a strong feeling that the entire WMO documents are not consistent in that terminology. At least the Technical Regulation says that height is "The vertical distance of a level, a point or an object considered as a point, measured from a specified datum."

So I share your concern on misunderstanding in using 0-3-6, 0-6-26, or 0-6-27.

Best Regards,
Eizi

[etoyoda]

I forgot to say, it could be plausible to deprecate older ones if it is deemed unclear.

[marqh]

@etoyoda many thanks for sharing your perspective on this with me.

I think that on the basis of this exploration, I will pursue the approach of requesting targeted definitions of new code table entries within code table 4.2 for the known cases that are causing us issue.

I shall do this in a separate ticket, with a reference to this discussion.

i will also look to raise another separate issue within GRIB3 to look at how to handle vertical datum definitions and references within the GRIB3 specification.

[etoyoda]

Just FYI to members, CF conventions share the same terminology "altitude is AMSL, height is AGL:" https://cfconventions.org/Data/cf-standard-names/77/build/cf-standard-name-table.html