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 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 station
    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.

does anyone on the list have a contact at EUMETNET OPERA and Spanish National Met Service (AEMET) who can help clear this up?

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