#118 closed defect (fixed)
bufr2ropp not creating all OC field
| Reported by: | Dave Offiler | Owned by: | Dave Offiler |
|---|---|---|---|
| Priority: | normal | Milestone: | 1.1 |
| Component: | ROPP (all) | Version: | 1.0 |
| Keywords: | BUFR ROPP Originating Centre | Cc: |
Description
ropp2bufr uses roppbufrcodes.nl as a look-up table to decode BUFR integer code values to text strings for the netCDF (or text) output files.
Axel reported that GRAS BUFR encoded with Originating Centre = 254 (EUMETSAT) was being decoded as 'UNKN'. This was because the look-up table did not contain info on this OC. Now added at [1176]. bufr2ropp now correctly detects BUFR OC=254 to be from Eumetsat, which should allow ropp2bufr to re-encode such files with BUFR OC=254 (not tested at this time).
However, ropp2bufr is just extracting and saving the first 4 characters ('EUME') in the OC text field. The intent was to re-create the full name and description from the look-up table (ie as in file roppbufrcodes.nl) in the text OC field. This needs investigating why this isn't happening. (It had been tested to work with GFZ)
Change history (3)
comment:1 by , 17 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
comment:3 by , 16 years ago
| Milestone: | → 1.1 |
|---|
bufr2ropp.f90 (s/r ConvertCodes) modified to generate %Processing_Centre string according to ROPP Interface Format Spec document.
String now consists of centre ID (ORGlist name, padded with spaces as necessary to a minimum of 4 characters) followed by a space and then ORGname string from the look-up table (roppbufrcodes.nl or built-in default).
Tested OK with sample EUMETSAT and GFZ BUFR files.
Committed as part of [1177].