NOTE: The bufrtables mailing list is no longer active. The list archives are made available for historical reasons.
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@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 ...
_______________________________________________
bufrtables mailing list
bufrtables@xxxxxxxxxxxxxxxx
For list information or to unsubscribe, visit:
http://www.unidata.ucar.edu/mailing_lists/
bufrtables archives: