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 versionsDear 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:descriptor> cannot be changed between table versions, but these parameters mayHello Jeff,You are right that scale, reference value and data width of abe changed with introducing of a new version of the Master Table!!!It is the reason, why the number of version is included inSection 1.document> has been already discussed and you did not express any objections toThe 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 athttp://www.wmo.int/pages/prog/www/ISS/Meetings/CT-MTDCF-ET- DRC_Geneva2008/DocPlan.html, where a change of datawidth and reference value of several descriptors from Class 14 isproposed to be introduced with a new table version. And thisdescriptors.>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 soonwe would end up with saturated tables full of deprecatedWith regards, Eva Dr Eva Cervena Czech Hydrometeorological Institute