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,
Andrew K. Mirza Senior Applied Scientist (Aviation)
Met Office FitzRoy Road Exeter Devon EX1 3PB United Kingdom
Tel: +44 (0)1392 884108 Fax: 0870 9005050
My 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"
... 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 ->
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 mailing list
For list information or to unsubscribe, visit: