Our approach was more like Yves´s one. But, as I said, we stopped the
development at INMET. But I would like to "hear" the discussion. I like this
topic very much.
----- Original Message -----
From: "Pelletier,Yves [CMC]" <Yves.Pelletier@xxxxxxxx>
To: "Jeff Ator" <Jeff.Ator@xxxxxxxx>; "Eric Wise" <wisee@xxxxxxxxxxxxx>;
"Paul Zamiska" <paul.zamiska@xxxxxxxxxxx>; <leslie.baran@xxxxxxxx>; "Lamar
Troutman" <lamar.troutman@xxxxxxxx>; "Enrico Fucile"
<enrico.fucile@xxxxxxxxx>; "Sibylle Krebber" <Sibylle.Krebber@xxxxxx>;
"Atsushi Shimazaki" <AShimazaki@xxxxxxx>; "Eizi Toyoda"
<toyoda@xxxxxxxxxxxxxxxx>; "Richard Weedon"
<richard.weedon@xxxxxxxxxxxxxxxx>; "Simon Elliott"
<Simon.Elliott@xxxxxxxxxxxx>; "Jose Mauro de Rezende" <jmauro@xxxxxxxxxxxx>;
"Weiqing Qu" <w.qu@xxxxxxxxxx>; "Stan Kellett"
Sent: Friday, June 17, 2011 10:42 AM
Subject: RE: BUFR and GRIB2 table information in relational DB?
CMC is working on putting its BUFR tables into a relational database. Our
main goal is relatively modest: it is to provide a web-based human interface
to browse and update the Tables, to replace the error-prone process of
manually updating a large ASCII file. But we are mindful of other possible
advantages such as improved programming interface.
We have a working prototype of a Table B interface. It is composed of a PHP
front-end and MySQL back-end. We can enter new descriptors, change their
status (validation, pre-operational, operational), even change descriptor
definition while maintaining traceability and descriptor history across
Table version numbers. We want to be able to ingest directly WMO
computer-friendly Table updates, verify them and accept them into our
operational system. Furthermore we want to be able to publish Tables in
backward-compatible ASCII formats.
Development has been slow, due to other projects competing for the
resources, but it is progressing. Our next step would be to develop a
similar interface for Table D. We also need to integrate code and flag
tables that are referred to by Table B descriptors.
We can talk about this more, off-line, if you wish.
De : Jeff Ator [mailto:Jeff.Ator@xxxxxxxx]
Envoyé : 16 June, 2011 13:00
À : Eric Wise; Paul Zamiska; leslie.baran@xxxxxxxx; Lamar Troutman; Enrico
Fucile; Sibylle Krebber; Atsushi Shimazaki; Eizi Toyoda; Richard Weedon;
Pelletier,Yves [CMC]; Simon Elliott; Jose Mauro de Rezende; Weiqing Qu; Stan
Objet : BUFR and GRIB2 table information in relational DB?
This is more of a general survey question. Here at NCEP, we currently have
our BUFR and GRIB2 master table information scattered across a bunch of
ASCII tables, web pages and system files. We're thinking about designing
and implementing a relational database to store all of this information in
one place, and then developing methods to allow the information to be easily
exported from the database into the specific formats we need for all of our
APIs and other operational tasks. We believe the BUFR and GRIB2 tables lend
themselves well to relational database design (especially when multiple
versions of tables including local entries need to be stored), and having
one master repository would alleviate problems we're currently having
keeping information synchronized across multiple system files and documents.
My question is, has anyone out there ever done or thought about doing this
type of thing? If so, we'd be interested to correspond with you about your
experiences, issues encountered, best practices, etc. and explore any
possible avenues for collaboration. It's hard for us to believe that nobody
else has ever thought of this before, so if at all possible we'd like to
benefit from any existing experience in the community and avoid re-inventing
the proverbial wheel.
Please let me know if you have any thoughts or experience in this area that
you'd be willing to share. Either way, thanks for your time and
With best regards,