-
Notifications
You must be signed in to change notification settings - Fork 9
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
code table 4.2 height (agl) and altitude (amsl) disambiguation #109
Comments
@richardweedon and @sebvi will follow up |
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:
I believe this is sufficient but if not, I would recommend to create new types of level than new parameters. |
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 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 |
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 |
similar to the above example, our models are outputing model fields for
where the type of fixed Surface is |
I am struggling somewhat to understand the philosophy statement from @sebvi:
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? |
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 |
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?
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. |
@marqh maybe we should organise a quick meeting to discuss this, what do you think? |
@sebvi : absolutely, let us discuss this; thank you regarding:
This implication does not seem to be defined in the Manual on Codes code table 4.5 is definitive, using the text
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 |
discussion continues. all are invited to provide feedback |
@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:
|
i have discussed this issue in more depth with @sebvi I think that the critical issue for my organisation is the provision of
there is an existing entry:
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. 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. |
@marqh @richardweedon @sebvi - it looks like the conversation is still open and will not be ready for FT22-1. |
@marqh @richardweedon @sebvi branch is created and updated. Please review the note associated with the deprecated value. |
@amilan17 it seems there is an error in the line:
this should be
can you correct it in the branch? |
@marqh @richardweedon @sebvi @jitsukoh Please review the note associated with the deprecated value.
|
@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:
|
hello @amilan17 many thanks to you and the team for progressing this please may i ask:
many thanks |
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. |
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 are
|
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 termaltitude
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
andheight 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
The text was updated successfully, but these errors were encountered: