You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Just flagging up that 95 abbreviations are associated with multiple parameters:
A lot look like duplication. I assume that what has happened is that a specific center first defines a new parameter in their local param table, and then that parameter gets accepted into the master GRIB table. But I'm guessing!
Although that doesn't explain why some abbreviations (like 4LFTX) is associated with two params in the master table which are identical except for their param number. I'm guessing the problem here is that the GDAL "master table" was generated by scraping the NCEP HTML pages (source), but these HTML pages include both the master tables and the NCEP local params.
Some initial thoughts on how to resolve this:
When decoding an abbreviation string from a .idx file, perhaps all users really care about is the long name and the unit? So, if all the params associated with a given abbreviation have identical names and units, then we just return those. (The comparison of names should be insensitive to capitalisation).
Some abbreviations (like CDCT) are associated with completely different parameters in the master table (cloud type and cloud top, in the cast of CDCT). Here, I think we just have to manually look at the docs for the NWP in question to figure out which is which and hard-code that conversion for that NWP. (This is an advantage of storing the mapping from abbreviation to name and unit in the hypergrib metadata for each NWP: It means we have an opportunity to find the correct mapping for each NWP).
This table was produced using grib_tables::parameter::database::describe_abbrevs_with_multiple_params().
Just flagging up that 95 abbreviations are associated with multiple parameters:
A lot look like duplication. I assume that what has happened is that a specific center first defines a new parameter in their local param table, and then that parameter gets accepted into the master GRIB table. But I'm guessing!
Although that doesn't explain why some abbreviations (like
4LFTX
) is associated with two params in the master table which are identical except for their param number. I'm guessing the problem here is that the GDAL "master table" was generated by scraping the NCEP HTML pages (source), but these HTML pages include both the master tables and the NCEP local params.Some initial thoughts on how to resolve this:
.idx
file, perhaps all users really care about is the long name and the unit? So, if all the params associated with a given abbreviation have identical names and units, then we just return those. (The comparison of names should be insensitive to capitalisation).CDCT
) are associated with completely different parameters in the master table (cloud type
andcloud top
, in the cast ofCDCT
). Here, I think we just have to manually look at the docs for the NWP in question to figure out which is which and hard-code that conversion for that NWP. (This is an advantage of storing the mapping from abbreviation to name and unit in thehypergrib
metadata for each NWP: It means we have an opportunity to find the correct mapping for each NWP).This table was produced using
grib_tables::parameter::database::describe_abbrevs_with_multiple_params()
.The text was updated successfully, but these errors were encountered: