NOTE: The bufrtables mailing list is no longer active. The list archives are made available for historical reasons.
Hi Milan: Sorry I was unclear about the checksum idea. The checksum is on the tables, not on the data. The intention is only to ensure that the coder and the decoder use the same tables. You would have to have a central place where tables can be registered, and a coder would have to make sure that their tables were registered. The registration center (eg WMO) would generate the checksum, and the coder would put it into the BUFR message. A decoder would read the message, get the checksum, see if they already had those tables locally, and if not, request them from the registration center using the checksum. My fear is that, without something like that, after a few years BUFR messages will no longer be reliably decoded. Or they can only be decoded by the original software that generated them, which becomes harder and harder to maintain. Regards, John Milan Dragosavac wrote:
Hi John,Unfortunately something like this can not be done because of various reasons. The tables are loaded based on the information in section 1 and expansion of data descriptors can start. Then one can find if really local entries are used. Checksum can not help because of possible compression and in this case the size of data vary. The Ecmwf experienceshow that you have to know anyway what data you want to process and thanbefore you start operational usage links are created in advance if needed. It is not too bad situation. In our preprocessing we repack all the data and use usually one version of the tables for all data afterwards.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
bufrtables archives: