Re: [bufrtables] More on table versions

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

Dear Jeff,

I am not sure, but I think we discussed this during our last meeting when Eva end people doing radiation find the problem.

I checked bufr regulations and there is nothing which state that we can not have different content in the different tables (different master table version number). What we always kept firm is that once the entry is in the particular version it can not be changed which is logical. In the Bufr Manual we have under Note 5 list of different tables and dates of implementation.
What happens in practice is even more complicated. The data are coming
in many different master table version numbers from 2 to 13 and usually
the local version number is used although there is no local entries. So data processing centres must have many tables to be able to process data although WMO maintains and keep the latest. Data producers should pay more attention on this issue.

In the past we had the case when the content of the tables was changed. That was from version 0 or 1 to 2 for class 13 elements where units were changed to SI units and consequently scales and in one case data width.

I propose that we discuss this issue again at the next Meeting.

Best regards


Milan Dragosavac

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

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,

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