Re: [bufrtables] More on table versions

  • Subject: Re: [bufrtables] More on table versions
  • From: John Caron <caron@xxxxxxxxxxxxxxxx>
  • Date: Sat, 23 Aug 2008 11:17:18 -0600
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 9005050
E-mail: andrew.mirza@xxxxxxxxxxxxxxxx

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"
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 ...