Need API support for importing foreign BUFR tables

Registered by vanh souvanlasy on 2009-05-01

*Christophe Beauregard wrote:
we need to ensure library users can easily build tables in the
API from non-CMC formats.

We have functions to create Table B and D entries, and new tables, but adding
entries to the tables isn't documented, although it may just use existing array
functions.

Okay... following the code, the process looks roughly like this (both both B and
D):

  BUFR_Tables* tbls = bufr_create_tables();
  foreach( element in master tableB ) {
    EntryTableB *etb = bufr_new_EntryTableB();
    load table entry data into etb;
    arr_add( tbls->master.tableB, (char *)&etb );
  }
  arr_sort( tbls->master.tableB, compare_tableb );
  tbls->master.tableBtype = TYPE_REFERENCED;

  foreach( element in local tableB ) {
    EntryTableB *etb = bufr_new_EntryTableB();
    load table entry data into etb;
    arr_add( tbls->local.tableB, (char *)&etb );
  }
  arr_sort( tbls->local.tableB, compare_tableb );
  tbls->local.tableBtype = TYPE_REFERENCED;

  /* repeat for table D */

This exposes more internals than seems reasonable. I'd recommend for starters
that it be simplified to something like:

  BUFR_Tables* tbls = bufr_create_tables();
  foreach( element in master tableB ) {
    EntryTableB *etb = bufr_new_EntryTableB();
    load table entry data into etb;
    bufr_add_master_tableB( tbls, etb );
  }

  foreach( element in local tableB ) {
    EntryTableB *etb = bufr_new_EntryTableB();
    load table entry data into etb;
    bufr_add_local_tableB( tbls, etb );
  }

  /* repeat for table D */

  bufr_sort_tables( tbls );

One could also implicitly do a sort in bufr_add_*, but that wouldn't be efficient
in a loop. At the very least we'd want to make sure the implicit sort uses a
linear insertion sort versus quicksort.

The second thing we should be thinking about is making sure each BUFR_Table has
some useful meta-data.

Master version, local version, local center would be minimum. Nobody can sanely
manage BUFR tables without that stuff.

A BUFR Edition flag might be useful (i.e. some newer descriptors might
desire/require IEEE FP for full range representation).

Some kind of "table status" flag might also be necessary (validation,
operational, etc).

Blueprint information

Status:
Not started
Approver:
None
Priority:
Medium
Drafter:
None
Direction:
Needs approval
Assignee:
None
Definition:
Discussion
Series goal:
None
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.