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 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,

Milan Dragosavac wrote:
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.



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

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 > > 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: