On 8/4/2011 3:18 PM, "Antonio S. Cofiño" wrote:
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
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 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
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
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.
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
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.
To this aim I'm was looking into the current BUFRIosp implementation
that comes with the netcdf-java library and I was able to access the
information of the DataDescriptorSection, but after many debug and
coding reading I was not able to discover how to access the data
itself coded into the BUFR keys
once you have a netcdfFile object, you get the top level Variable out of
it and call read() or read(Section) on it. You get back an Array, but
its an ArraySequence which requires some special handling. have a look
at this for an overview:
have a look at ucar.nc2.NCdumpW for example use.
Could you provide me some ideas about what is the best way to access
the data encoded into the BUFR message?
Thank you and regards.
netcdf-java mailing list
For list information or to unsubscribe, visit: