id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
186	Updates to BUFR Section 1	Dave Offiler	Dave Offiler	"Decisions taken at the first meeting of the ''INTER-PROGRAMME EXPERT TEAM ON DATA REPRESENTATION AND CODES (Geneva, 15 - 18 September 2009)'' - see
http://www.wmo.int/pages/prog/www/ISS/Meetings/IPET-DRC_Geneva2009/IPET-DRC_DocPlan.html has knock-on consequences for the ROPP BUFR encoder.

Specifically, these affect the details encoded into BUFR Section 1
via the ropp2bufr tool in ropp_io:

'''a) Local Table Version Number'''

Octet 12 in BUFR Edition 3 (Octet 15 in Ed.4) is clarified to be encoded as zero when there are no local descriptors being used (i.e. all descriptors are from the Master Table).

Currently, ropp2bufr has a hard-coded value of '-99' which (supposedly) indicates the default value, to be actually set by the MetDB encoder routine enbufv2(). According to the comments in this latter routine, the default is '0' (as expected), but -99 is not actually tested (as some other defaults are), and the encoded value is not defined; in practice, it seems to be encoded as '1'. This bug has been notified to the MetDB team.

When GFZ started using ropp2bufr for CHAMP & GRACE-A, sending the BUFR files to DWD for insertion onto the GTS/RMDCN, DWD actually
insisted that '0' was anyway incorrect, and '1' was the correct value, so it was left like that.

On the other hand, Milan Dragosavac (ECMWF) believes that when no local tables are being used, this octet should be coded as '255'. 

The IPET clarifies that '0' is the correct value in these circumstances, so !VerLocTable in ropp2bufr should be hard-coded as '0' to work-around the MetDB bug noted above.

Since this value is used to build the ECMWF decoder look-up table
file names, users must be given due warning before this change
is implemented for GTS/RMDCN dissemination.


'''b) Data Sub-Category'''

The 2008 BUFR Tables mini-update introduced several sub-categories to Common Code Table C-13 (which is used in conjunction with Table A) for Octet 12 in Edition 4. This
octet defines an 'International data sub-category' 
Amongst the new entries for Data category 3 (Satellite Sounding) is GPSRO with a code value 50, tagged 'awaiting validation'.

For BUFR edition 3, octet 10 (and octet 13 in Ed.4) is a locally-defined data sub-type. This is currently encoded as 255 (implying unknown/missing) in ropp2bufr. This octet, not having had any special value thus far, should be encoded as 50, and this value
also adopted for Octet 13 for a future Ed.4.

While this code change will alter the value encoded in Section 1, as far as we are aware, no use is made of it today. However, notice to users should be given at the same time as for change (a).   


'''c) Master Table Version Number'''

Not an IPET issue, but ropp2bufr uses -99 for the (default) master table version. The current v18 MetDB enbufrv2() routine
substitutes '13', but this is liable to change with future library releases having updated BUFR tables. Advice now is that this value should be fixed unless the Table D sequence, or any Table B element is changed for the data being encoded, which would then warrant an updated table version number.

Hence !VerMasTable in ropp2bufr should be hard-coded as '13' in place of '-99'.

This code change will not alter the value actually encoded into BUFR Section 1, but merely fix the current value until explicitly changed within the app.


'''d) Master Table'''

Currently, ropp2bufr codes Master Table as -99, again for enbufv2 to convert - in this case to '0' for 'meteorology'. This should be hard-coded to '0' for future compatibility with the ECMWF BUFR library which does not employ such defaults.

This code change would not alter the value actually encoded into BUFR Section 1 currently.


All of the above changes should also be implemented when portign to the ECMWF BUFR library (see Ticket #177)"	enhancement	closed	normal	4.0	ropp_io	3.0	fixed	BUFR, Section 1