code table 4.2 height (agl) and altitude (amsl) disambiguation

[marqh]

Branch

https://github.com/wmo-im/GRIB2/tree/iss109

Summary and purpose

provide new code table entries within code table 4.2 to ensure clarity and disambiguation between altitude above mean sea level and height above ground level

Action proposed

The Team is requested to review the proposed new parameter and approve it for implementation.

Discussions

There is concern that certain code table entries within code table 4.2 are not clear with regard to where heights are being measured from, the difference between using mean sea level as a vertical datum and using the ground surface as a vertical level.
concerns and context are available within the discussion: #105

There is no clear distinction between the use of the term height and the term altitude within the GRIB2 specification and these terms are both used within code table 4.2. Often only one term is provided in a particular context, e.g. 0-3-6 geometric height. it is hard for an implementer of the Specification or a user of the data to have confidence whether this is referring to height above mean sea level or height above ground.

The terminology for added items uses the phrasing altitude above mean sea level and height above ground level, consistent with this teminology's use in code table 4.5.

The term Geometric is used sporadically, but not consistently across code table 4.2. It is included in the current proposal, but for discussion; I can see reasons to use it consistently and reasons to not use it consistently, so consideration on this detail point would be helpful.

Detailed proposal

• New code table entries are requested for code table 4.2
  • Product discipline 0 – Meteorological products, parameter category 3: mass
    • Geometric altitude above mean sea level m
    • Geometric height above ground level m
• Deprecation of existing entry (in favour of the new codes)
  • Product discipline 0 – Meteorological products, parameter category 3: mass
    • 0-3-6 Geometric height

[amilan17]

@richardweedon and @sebvi will follow up

[sebvi]

It seems to me that the disambiguation should come from the type of Level used and should not be encoded in the parameter itself.

We have in code table 4.5:	code	meaning	units
102	Specific altitude above mean sea level	m
103	Specified height level above ground	m

I believe this is sufficient but if not, I would recommend to create new types of level than new parameters.

[marqh]

Hello @sebvi

I am struggling to understand how to apply your thought process here, perhaps you can help me?

the level code in code table 4.5 describes how to interpret the vertical level, endoded within the message

consider that a model outputs a quantity which is the height above local ground surface for each of a number of isothermal levels and a second quantity which is altitude above mean sea level for each of a number of isothermal levels

each GRIB2 message would specify a temperature value quantity as heightOfFirstFixedSurface and endthe codeTable4.5 value of 20 isothermal level

the data payload is a set of either height (agl) or altitude (amsl) values, with units of m

So, how can the type of first fixed surface be used to specify isothermal levels and also Be used to define how to interpret the entry from codeTable4.2?

It seems like different codeTable4.2 code table entries are needed to differentiate this quantity difference.

we have numerous cases like this that we are trying to support

thank you for your help marqh

[sebvi]

I have thought about it over night and I now understand what is the goal: the data section contains either an altitude or a height, it is not an observable measure at that altitude or height.

I still strongly disagree with the proposal because it break the philosophy of GRIB2 by introducing "location" into the observable. The location is specified using type of levels from code table 4.5. Essentially, what is measured is always an altitude or a height defined by 2 levels.

For instance, "Geometric height above ground level of convective cloud base" should be encoded discipline 0, category 3, entry 6 for "geometric height", then the typeOfFirstFixedSurface = 1 (surface) and typeOfSecondFixedSurface=26 (convective cloud base)

For "Geometric altitude above mean sea level of convective cloud base" we would need a new generic parameter "geometric altitude" in discipline 0 category 3, and then use typeOfFirstFixedSurface = 101 (mean sea level) and typeOfSecondFixedSurface=26 (convective cloud base)

The same principle can be used to encoded all the parameters above

[marqh]

similar to the above example, our models are outputing model fields for

height above ground level on pressure levels

altitude above mean sea level on pressure levels

where the type of fixed Surface is 100: Isobaric surface with values of pressure for the vertical coordinate

[marqh]

I am struggling somewhat to understand the philosophy statement from @sebvi:

the philosophy of GRIB2 by introducing "location" into the observable.

as the observables in these cases are locations, the codeTable 4.2 entry is a vertical location

Is this philosphy written in the Manual somewhere?

[marqh]

@sebvi

please may i enquire about the use of two different fixed surface type definitions you describe?

How is the approach of using 1 fixed surface type to denote the vertical datum to be used with respect to the data payload quantity and another to denote the definition of the vertical coordinate value specified within the manual on codes?

How does an implementer know which of these is the firstFixedSurface and which is the secondFixedSurface?

Based on the Manual on codes, our implementers have always bound the typeOfFirstFixedSurface to the value given in the scaledValueOfFirstFixedSurface ans the typeOfSecondFixedSurface to the value given in the scaledValueOfSecondFixedSurface

we have not found any specification nor indication of applying either typeOfXFixedSurface to the data payload within the manual

[sebvi]

it seems we have posted simultaneously @marqh

Do you agree that using "height" implies that it is "above ground level" and that "altitude" implies that it is "above mean sea level" because it is part of their definitions?

as the observables in these cases are locations

your 2 observables are not locations but the distance between a reference (msl or surface) and a location.

If you want to express heights of model or pressure levels, I would use the discipline/category/number that defines the observable height (which implies above ground level) and set the typeOfsecondFixedSurface to either 100 and 105 if your model levels are hybrid levels.

[sebvi]

@marqh maybe we should organise a quick meeting to discuss this, what do you think?

[marqh]

@sebvi : absolutely, let us discuss this; thank you

regarding:

Do you agree that using "height" implies that it is "above ground level" and that "altitude" implies that it is "above mean sea level" because it is part of their definitions?

This implication does not seem to be defined in the Manual on Codes

code table 4.5 is definitive, using the text

Specific altitude above mean sea level | 102 
Specified height level above ground | 103 

i have been unable to find a specification within the manual on how to interpret the term "height" without qualification.

this appears to be a specification gap within the manual and a difference in terminology use between codeTable4.2 and codeTable4.5

[amilan17]

discussion continues. all are invited to provide feedback

[sebvi]

@marqh I fully agree that entries in code table 4.2 are imprecise compared to code table 4.5.

We have several options to clarify this. We could: 1) add some supporting text to clarify the entries in code table 4.2 2) rename all entries containing "height" and "altitude" to state the reference like in code table 4.5 (and eventually create missing height/altitude) 3) keep the existing entries as is in case those are used in a different way and create new entries with proper reference (but keep the upper extend encoded by a type of level from code table 4.5)

[marqh]

i have discussed this issue in more depth with @sebvi

I think that the critical issue for my organisation is the provision of

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

there is an existing entry:

• 0-3-6 | Geometric height

which is ambiguous, as the term 'height' is not specified within the manual on codes so no datum can be confidently interpreted

I proposed marking 0-3-6 as deprecated in favour of the two new unambiguous entries.

The further new codes within the original proposal were found by me from searches within the manual, but are not of immediate need. @sebvi provide reasoning why the pattern of a limited number of existing entries encoding a fixed surface type within the 4.2 entry is not a good pattern, and that it would be better not to encourage this with additional entries

UK does not have a pressing need in this space, we are content using the fixed surface definitions in 4.5, as long as unambiguos differentiation between altitude above mean sea level and height above ground are defined

As such, i am going to update the porposal text to focus only on these entries.

[amilan17]

@marqh @richardweedon @sebvi - it looks like the conversation is still open and will not be ready for FT22-1.

[sebvi]

@amilan17 & @jitsukoh I think we reached a consensus. The proposal was updated accordingly. If the branch is up-to-date, i.e. reflecting the new proposed changes, then I think it is good to go.

[amilan17]

@marqh @richardweedon @sebvi branch is created and updated. Please review the note associated with the deprecated value. 

589c335

[jitsukoh]

@amilan17 it seems there is an error in the line:

Parameter number by product discipline and parameter category,"Product discipline 0 - Meteorological products, parameter category 3: mass",33,,,Geometric height above ground level,,m,Operational

this should be

Parameter number by product discipline and parameter category,"Product discipline 0 - Meteorological products, parameter category 3: mass",33,,Geometric height above ground level,,,m,Operational

can you correct it in the branch?

[amilan17]

@marqh @richardweedon @sebvi @jitsukoh Please review the note associated with the deprecated value. 

Geometric height is deprecated, because it does not indicate whether this is referring to height above mean sea level or height above ground. Use code 32 or 33 instead."

[jitsukoh]

@amilan17 @marqh @richardweedon @sebvi We avoid the use of word "deprecated" because the meaning is ambiguous and it caused problems in the past. Following existing practices, I would suggest:

Code figure 32 (Geometric altitude above mean sea level) or 33 (Geometric height above ground level) should be used instead of figure 6 (Geometric height), because it does not indicate whether this is referring to height above mean sea level or height above ground.

[mo-marqh]

hello @amilan17

many thanks to you and the team for progressing this

please may i ask:

1. when may we start using this code?
2. what table version should be used in the GRIB messages to ensure reference to these codes is valid?

many thanks mark

[amilan17]

The implementation date is set for May 15, but if they are adopted earlier by WMO, they might be available for use in April. The version number will be 29.

[marqh]

of note to future readers of this issue, the comments of Dec 2021 make incorrect reference to the defining numbers used for these new parameters

the correct values, as published within https://github.com/wmo-im/GRIB2/blob/master/txt/CodeFlag.txt#L711 & https://community.wmo.int/activity-areas/wis/latest-version (v29.1) & https://library.wmo.int/index.php?lvl=notice_display&id=10684#.X18yfpMza3I (2022 update)

are

• Code table 4.2 "Product discipline 0 - Meteorological products, parameter category 3: mass",
  • 33 Geometric altitude above mean sea level (m)
  • 34 Geometric height above ground level (m)