Re: [netcdf-java] Accessing to BUFR message DataSection

Hi John, Antonio,


Opera has indeed used originating center value 255 (missing value) for a while, 
but Opera members should be steering away from that. This practice makes Opera 
data hard to use with non Opera created decoding software.

As you can see hereunder 247 should be the correct originating center for Opera 


Ernst de Vreede



A quote from:


3.1   Value of originating center

In BUFR language, every «originating center» (in practice every NMS and some 
international bodies, e.g. ECMWF, are originating centers) has the right to 
define its own local set of descriptors.  A given number identifies such an 
originating center. OPERA is not recognized as such a center, and so has not 
his assigned number.

This is a problem if OPERA needs to define radar specific descriptors.  It is not 
possible to ask each OPERA member to add the OPERA descriptors to their local 
tables, as this leads to conflicts. For instance descriptor 3 21 192 is in OPERA 
a 4 bit reflectivity image, and in France it is used for calibration results.

The solution devised so far by OPERA was to piggyback on the missing value for 
the originating center field in the message. This value is 255 or 65535 
depending on the BUFR edition used (see 3.3).

Since summer 2008, WMO has allocated 247 as the official «originating center» 
for OPERA. It is not decided currently how OPERA members will handle the 




Van: netcdf-java-bounces@xxxxxxxxxxxxxxxx 
[mailto:netcdf-java-bounces@xxxxxxxxxxxxxxxx] Namens John Caron
Verzonden: woensdag 10 augustus 2011 3:50
Aan: "Antonio S. Cofiño"
CC: netcdf-java@xxxxxxxxxxxxxxxx
Onderwerp: Re: [netcdf-java] Accessing to BUFR message DataSection


On 8/8/2011 3:42 AM, "Antonio S. Cofiño" wrote: 

Antonio S. Cofiño
Grupo de Meteorología de Santander
Dep. de Matemática Aplicada y 
        Ciencias de la Computación
Universidad de Cantabria
Escuela de Caminos
Avenida de los Castros, 44
39005 Santander, Spain
Tel: (+34) 942 20 1731
Fax: (+34) 942 20 1703

El 05/08/2011 14:09, John Caron escribió: 

Hi Antonio:

On 8/4/2011 3:18 PM, "Antonio S. Cofiño" wrote: 

Dear John, 

I'm trying to create an IOSP for some radar images coded in BUFR format using 
the EUMETNET OPERA coder. I'm attaching an example file which is a "RLE" 
compressed image of 480x480 pixels (each pixel is a byte). 

With the TableB, TableD and the corresponding line from the tablelook.csv files 
attached I'm able to decode the message, and It was possible to open the file 
using the ToolsUI's BUFR IOSP explorer and read the RLE encoded information. 

ok, im seeing 

 BUFR edition 4 time= Thu Dec 02 02:10:19 MST 2010 wmoHeader= hash=[0x5f799858] 
listHash=[0xfc50e783] (-61806717) 
   Category= 6.0.0=Radar data / Reflectivity data 
   Center= 255.255 (Missing value) 
   Table= 0.13.5 
    Table B= wmoTable= wmo.v13.composite localTable= none mode=wmoOnly
    Table D= wmoTable= resource:/resources/bufrTables/wmo/TableD-121509.csv 
<resource://resources/bufrTables/wmo/TableD-121509.csv>  localTable= none
  DDS nsubsets=1 type=0x80 isObs=true isCompressed=false
  startPos=0 len=61116 endPos=61116 dataStart=76 dataLen=61036 dataEnd=61112 
    3-1-1   : 
      0-1-1   : WMO block number
      0-1-2   : WMO station number
    3-01-192: NOT FOUND!!
    0-7-1   : Height of stationHe
    0-29-199: NOT FOUND!!
    0-29-200: NOT FOUND!!
    0-29-193: NOT FOUND!!
    0-29-194: NOT FOUND!!
    0-29-195: NOT FOUND!!
    0-29-196: NOT FOUND!!
    0-30-31 : Picture type
    0-29-2  : Co-ordinate grid type
    0-33-3  : Quality information
    3-13-9  : (Radar reflectivity values)
      0-21-1  : Horizontal reflectivity
      1-01-000: replication
      0-31-1  : Delayed descriptor replication factor
      0-21-1  : Horizontal reflectivity
    0-2-3   : Type of measuring equipment used
    0-2-121 : Mean frequency
    0-2-125 : Pulse repetition frequency
    0-25-3  : Number of integrated pulses
    0-2-135 : Antenna elevation
    3-21-193: NOT FOUND!!

so its fine that local tables are being used, but to not encode the center 
(Center= 255.255 (Missing value)) makes this record unreadable by generic 
software, as there's no way to know what local table to use.

Yes, you are right using a missing coded value to encode the Center is a bad 
idea. By the way, to decode the local usage, you can use the tables attached in 
the previous e-mail.

who wrote this file?  EUMETNET OPERA ? 

        could you contact them and ask them to put in the correct 
center/subcenter info? Ask them to check that the table info is correct also.

The file has been written and published by the Spanish National Met  Service 
(AEMET) in their public FTP server:

In the doc that is been published, it's been mentioned that the software that 
can be used to decode the radar data is the one published by EUMETNET OPERA 
therefore my understanding is that also this software it's been used to code 
the data.

One of the issues is that the ToolsUI's ncdump utility crash when I'm tryng to 
dump the corresponding data for the different Sequences in the Netcdf object 
generated by the existing BUFRIosp. 

yes, its a bit buggy with sequences. what you really want to do is to select 
the bufr record in the Viewer tab and right click on "data table". If there are 
nested sequences, select a record in the data table and right click on "show 
sequence n" (or something close to that).

ill try to clean up ncdump when i can.

The other problem that I'm having is that I would like to create my own IOSP 
for this BUFR datasets and generated a more convenient Netcdf object which take 
into account the kind of data that is encoded. 

Yes, this is what will have to be done to read BUFR on datasets where the 
standard interpretation of the structure is not the desired one. We will need 
some kind of plugin on top of a generic library. perhaps the first thing to do 
is to look at how CDM currently interprets this data, and then what it should 
be. I need to add your tables befoew I can see that, but the lack of a center 
means i have to kludge it in.

Hi Antonio:

ok, ive added the opera tables so i can see the BUFR structure. it appears to 
be a 480 x 480 grid (not radial data) ?

i havent read the OPERA_2006_14_BUFR_Guidelines.pdf too close, but it appears 
that they have extra conventions on top of BUFR. I think I agree that this 
should probably be a new IOSP. Is that something you are interested in doing?


  • 2011 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the netcdf-java archives: