Re: [bufrtables] More on table versions

NOTE: The bufrtables mailing list is no longer active. The list archives are made available for historical reasons.

Everyone,
To follow-up on the below issue, the WMO codes group discussed this at length during its annual meeting two weeks ago. After much discussion and debate, it was agreed to allow scale factors, reference values and/or bit widths (but *not* descriptor names nor units!) to change concurrent with the introduction of a new version of the BUFR tables. This policy will take effect beginning with the upcoming version #14. The current version #13 will remain a superset of all previous editions, so it will only practically be necessary for centers to maintain version #13 and then all versions going forward from that point. In particular, this will allow incorrect descriptors to be corrected in future versions as well as allow deprecated descriptors to be removed altogether, since such descriptors will remain valid for all time within the previous table version(s) in which they existed. So all archived BUFR messages will always remain valid and readable, but all users (not to mention their encoding and decoding software!) will now need to pay careful attention to which version of the tables they are working with at any given time.
It was well understood and agreed at the meeting that, for this new policy to succeed, the WMO secretariat will need to maintain official copies of the current and all future tables available on its web site, and in one or more formats which users can easily download and ingest into their local software (currently only MSWord and PDF formats are available). To that end, WMO has agreed to devote the necessary resources towards this task, and they will be assisted for an initial period of time by a small group of experts from the meeting, in sort of an ad-hoc advisory role, in order to get this process started. WMO has also agreed to set up an email list to notify users whenever such table updates are made to the web site.
The exact policy and procedures will be spelled out in the final report of the meeting (not yet available!), but at this point I wanted to give everyone a "heads-up" that this is coming. In particular, one procedure that was agreed upon was that any and all corrections to existing descriptors within a new table version must be made simultaneously when that table is first released for pre-operational use, in order to prevent any confusion amongst users who may engage in pre-operational dissemination of messages using that new table version before it officially becomes operational.
Let me know if there are any questions, and I also invite Milan, Eva, Stan and any other members of the codes group who happen to be on this email list to add to or clarify anything I've said. 

Best regards,
-Jeff


Jeff.Ator@xxxxxxxx wrote:

Dear Eva and Milan,

I must admit I'm confused now.  While I certainly agree that it's
possible, and perhaps even preferable, to be able to change the
characteristics of an existing descriptor when a table version number is
incremented, I don't recall that we ever formally agreed to adopt this
as the new practice.  Eva, I have read your 3.1.1(1) document, and I do
recall when we previously discussed the problems of these particular
radiation descriptors; however, I don't recall (nor do I see any mention
in the final reports from any of our previous meetings?) where we agreed
to this change in practice.  As you mentioned, in the past we've always
kept existing descriptors frozen and just deprecated and replaced them
with new descriptors whenever subsequent problems were discovered.  And
while I certainly remember past instances where we've discussed the
shortcomings (e.g. Table B classes rapidly filling up) of this type of
approach, I just don't remember where we ever formally agreed to change
it.  I apologize if my memory on this point is faulty, and if that is
the case could you please point me (and the rest of this mailing list as
well!) to any relevant documentation?

Personally, I have no problem with allowing descriptor characteristics
to change between table versions.  I do think it is workable and has
several benefits, which is probably why I didn't object if/when we did
previously agree to this as a group.  In my below email I was only
trying to describe the current policy (at least as I understood it) to
my colleagues on the mailing list.  As you mentioned, the big issue
involved with changing this would be that the Secretariat would now have
to maintain all of the old versions of the tables (and in a
machine-readable format! :-) somewhere on the WMO web server.  Assuming
Joel is agreeable to that, then I believe the majority of my colleagues
here in the U.S. would agree to it as well.

Thanks and best regards,
-Jeff


----- Original Message -----
From: Milan Dragosavac <Milan.Dragosavac@xxxxxxxxx>
Date: Wednesday, August 13, 2008 3:30 am
Subject: Re: [bufrtables] More on table versions


Dear Eva and Jeff,
I think that there is no problem to change data width, reference value and scale for different Master table version numbers of tables used.
If we could not do this the whole concept of master table version numbers and local table versions would be meaningless. The only requirement is that once the entry is in any of the tables and used, 
it must stay as such in that version of the tables. However the only
setback is that Secretariat must keep track of all versions even if
most entries in the next version is the same as in the previous.
That is the way we are going to correct radiation elements in the version 14. 

Regards

Milan


Milan Dragosavac

ECMWF
Shinfield Park, Reading, Berkshire, RG2 9AX, UK

Tel: (+44 118) 949 9403
Fax: (+44 118) 986 9450
Telex: 847908 ECMWF G
E-mail: milan.dragosavac@xxxxxxxxx


Eva Cervena wrote:

Hello Jeff,
You are right that scale, reference value and data width of a
descriptor> cannot be changed between table versions, but these parameters may 
be changed with introducing of a new version of the Master Table!!!
It is the reason, why the number of version is included in 
Section 1.

The information on the time of introduction of the descriptor may be
useful, but it is  not essential at all.

 I would like to refer to my Doc. 3.1.1(1), available at
http://www.wmo.int/pages/prog/www/ISS/Meetings/CT-MTDCF-ET- DRC_Geneva2008/DocPlan.html, where a change of data 
width and reference value of several descriptors from Class 14 is
proposed to be introduced with a new table version. And this
document> has been already discussed and you did not express any objections to 
the proposed approach.

Up to now, however, this ability of BUFR has not been much used,
i.e. the out-dated descriptors were deprecated and replaced
by new ones. Using this approach, the management of the tables
is simplified and only the last tables may be implemented in the SW.
But the deprecated element descriptors may be included in several
D-descriptors and these would have to be also deprecated, and soon
we would end up with saturated tables full of deprecated
descriptors.> 
With regards,
Eva

Dr Eva Cervena
Czech Hydrometeorological Institute
  • 2008 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the bufrtables archives: