NOTE: The bufrtables mailing list is no longer active. The list archives are made available for historical reasons.
Hi Andrew:I am in the process of writing a summary of similar musings, and while I hadnt thought of a "BUFR-2", it does seem be a useful exercise in clarifying "lessons learned". Ill be on vacation for 2 weeks, but I'll try to get some reasonable draft of that when im back.
Ill also try to have a real look at Gil's paper soon. The ISO work tends to be abstract, which makes for a good foundation, and there is still the work of deciding on the "engineering trade offs" of a specific data encoding. Perhaps writing down and reviewing the motivating requirements for BUFR would be important also. Regards, John Mirza, Andrew wrote:
Hello John, Milan, Since Chris as mooted on refactoring of BUFR, I thought I would share with you my own musings, which I have expressed to a few people. This will not assist you with the current problem under discussion - relating to bit-widths and tables but I consider this may be worthy of a wider, background discussion. Regards, Andrew. Andrew K. Mirza Senior Applied Scientist (Aviation) Met Office FitzRoy Road Exeter Devon EX1 3PB United Kingdom Tel: +44 (0)1392 884108 Fax: 0870 9005050E-mail: andrew.mirza@xxxxxxxxxxxxxxxxMy interest in this subject area derives from my involvement the FLYSAFE Project and the work being carried at Eurocontrol on the WXCM. ... My musings so far from the correspondence I have read leads me to think that maybe a "BUFR2" format should be considered - in the same manner that GRIB-1 is now being superseded by GRIB-2 (which I am working my way through at present). Such a format could clean-up the existing tables, incorporate the latest thinking for data exchange (and data modelling) now and for future requirements; and include new procedures for its maintenance; which could afford the avoidance of confusion by clearly separating the "newer & desired" from the "older & undesired"features...... Gil's work [comparison of BUFR to ISO] would be the starting point. In essence, the data model provides a map of the existing process, and what cannot fit into the map as far as ISO mapping. My musings are that we could cleanse the existing bufr tables removing any anomalies; extend the data model to incorporate the dynamic features; seek to change the bufr encoder/decoder to process in an extensible manner in a similar way to GRIB-2; explore how to incorporate a more flexible table management, including referencing to earlier tables (for backwards compatibility); then address the configuration management of the bufr standard, source code and tables... ... and - to help maintain consistent coding practice - I suggest that a user interface or user configuration manager be developed for BUFR and GRIB....relating to the aviation data link - is an xiBUFR; this would carry its own coding tables - just enough [table] data to decode the file; and would be a merge between binary-xml and BUFR... ... A bufr/grib api would be useful - perhaps based on ECMWF but personally I found this difficult to use, while I found the NCEP version more friendly it is perhaps not as functional as ECMWF; however, the coding manual is a nightmare to navigate - I ask myself the question why must I deal with this apparent complexity - that's why I have a computer - hence the user interface ...... A basic outline: BUFR/GRIB GUI -> creates cards -> -> CODEC ->de/coded file source data -> The cards are the interface between the GUI and the CODEC, and would specify the input parameters. The GUI would load the relevant International or Local Tables, and would include guidance in the form of helpful notes or reminders ...
bufrtables archives: