Table A "L" and "M" types...

petersilva commented 3 years ago

using the UNIDATA as a source for a "variety" of data we have encountered data types not defined by the international Tables. "L" and "M". What the heck are they?

We found some LTUS which are iwxxm's ... but a lot of them are binary...

they don't gunzip.
they don't have GRIB written in the beginning.

hmm...

@antje-s any ideas?

petersilva commented 3 years ago

MAZI98_KWBX_120000_3470e3a641dd3a9e25d1fbfa91e82ca3.gz

Sample.

petersilva commented 3 years ago

f330dea13020550c2a13a6406e4f9ad35d4bb929 ...

first guess:

made L and M types default .bin classification
make TableB entry for M a copy of L... hoping it is iwxxm versions of L ?

antje-s commented 3 years ago

"L" is used for IWXXM, for T2A1A2 the use should be similar to "F" bulletins

antje-s commented 3 years ago

https://library.wmo.int/doc_num.php?explnum_id=10469 p. 80 (last updated 2020) L - Aviation information in XML - B7 C1 C1 1/2 / 3

antje-s commented 3 years ago

"M" is for national use, we guess some uses "M" for model data

antje-s commented 3 years ago

My colleague found information on "M" data in the VolC1, an example is "6","MOSCOW","RUSSIAN FEDERATION","MOSCOW","28/03/2019","E","MQXY89","RUMS","FM 92-XIV","12","(90S-90N 0-358,5E), GLOBAL AREA FORMAT AT(1.5 X 1.5) H+216(GLOBAL MODEL GEPSH) ENSEMBLE MEAN OF MSL PRESSURE","XXX"

petersilva commented 3 years ago

"models" should that not mean it is GRIB? the sample provided isn't grib, and isn't gzipped... but it is American, rather than Russian.

antje-s commented 3 years ago

My first branch issue023 with following updates:

adding 'M' in TableA.json (L was already added, M was in TableB but missing in TableA)
updates for 'M' and 'L' in TableB.json (for M in TableB: MQ is used from RUMS for model data. Is it used in America for other types of data? In our WIS Catalogue there are no metadata so I added the entry as example)

I will now start a pull request. I hope the procedure is ok and I have not done anything wrong.

petersilva commented 3 years ago

Looks good, based on what we have... Accepted the merge. Is that as much as we plan to do? for example:


us/KWBE/national/MZHE00_KWBE

only maps to national... There was also... MAZI98_KWBX is still a mystery.

You mentiond MQ being used by the Russians, but since it is national, I guess it means different countries could assigne the letters differently?

Do we just close the issue leaving it like that, or do we leave it open and try to find some national people to tell us what their tables are, and we end up with a TableB eventually like so:


"M": { 
             "ru":  {
                     "Q": "model-grib",
             }
            "us" : {

            }
}

antje-s commented 3 years ago

Probably it really is best to leave TableB for 'M' blank as national could be used differently...

petersilva commented 3 years ago

OK, so in that case, we remove the "Q", and the job is done?

antje-s commented 3 years ago

yes, from my point of view we can do it that way

antje-s commented 3 years ago

direct in main code base or open a new branch issue023_2?

petersilva commented 3 years ago

I think just commit to the existing branch issue023... I do not see the need for another branch. perhaps do:

git checkout issue023
git merge main  # pull from main into issue023 that happenned since issue023 branched off.

then do changes, to make sure it keeps up with main. We don't need a branch per commit. Does that make sense?

antje-s commented 3 years ago

sounds good and thanks for the hint with the commando to get the latest main status to the already existing branch

petersilva commented 3 years ago

merged.

wmo-im / GTStoWIS2

Table A "L" and "M" types... #23