[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20021007: Uncompressing Distributed Radar Files

Anthony,

The products distributed for broadcast on NOAAPORT are zlib compressed 
(wmo header and all), and then wrapped with another uncompressed product 
header. The GEMPAK routines are layered for the navigation and display
driver sections independently, and if you are trying to use the
NEXRAD data in your own programs, then you are much better off
using a routine such as Dan Vietors ucnids.c. See:
http://weather.unisys.com/noaaport/src/ucnids.c
Since GEMPAK relies on common blocks to store various parts of
the file information, extracting pieces of the library 
will be cumbersome.

All of the software is designed to NOAA documentation of NEXRAD products
and NOAAPORT SBN broadcast documentation, so that would be the best source
for you to consult if you are trying to engineer your own solution.

If you are ftp'ing the NEXRAD products from weather.noaa.gov, for example:
ftp://weather.noaa.gov/SL.us008001/DF.of/DC.radar/DS.p19r0
in the SI.CCCC directories with the product names sn.xxxx,
then the product is not zlib compressed. If you do a byte dump of the
products, you will see that the first byte after the WMO and pil ID
following the \r \r \n sequence is a \0. If the products are compressed, that
will not be the case. 

Since the NEXRAD data uses halfwords, you will have to do bit manipulation to
read parts of the data independent of the byte ordering of the machine you
are on. NOAA is the source for documentation of the NEXRAD data format.

Steve Chiswell



>From: Anthony B Tang <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200210072306.g97N6d115979

>Unidata Support,
>
>Hi! I am trying to decompress the NOAAPORT distributed radar files and I was
>wondering if someone could point me in the right direction. Here is what I got
>so far ::
>
>I found a few files inside the GEMPAK code which explains about reading the
>NEXRAD data; imnexz.c and imnexhd.c I tried compiling them and moving them out
>to make a separate driver for those files which read NEXRAD data, but
>dependancies for these were A LOT. Is there any "easy" way to just get the
>NEXRAD reading files to compile alone?
>
>I couldn't get the files compiling on their own, so I used ucnids.c from Danie
> l
>Vietor from post #4889 and when I executed the program, it seemed like it
>didn't work because 1) The uncompressed file was only about 100bytes larger
>than the origonal and 2) The header (SDUS5 ..... ) was still there. I emailed
>him, but no response yet.
>
>The NEXRAD data files I got are distributed in the filenames sn.XXXX from
>NOAAPORT; am I right to say that the radar data from NOAAPORT have a
>uncompressed header and an zlib compressed body?
>
>I read from another post that the first two lines are the header and doing tai
> l
>+3 old_file > new_file would give you ONLY the zlib compressed portion in the
>new_file. If I do this and then suppose if I write a program which uses zlib t
> o
>decompress the whole new_file would the resulting file be RAW NEXRAD Level 3
>data? And once I get this working, how do I know it truly works? If possible,
>can you supply some sample data and results?
>
>Also, in your code, imnexz.c, it seemed like you did some bit-to-bit
>manipulations -- is this necessary?
>
>I tried all of the above and wrote code for parsing the bits and everytime I
>get message code # at 30344 or some number > 190.
>
>That's it. Thank you thank you thank you.
>
>=-Anthony
>
>__________________________________________________
>Do you Yahoo!?
>Faith Hill - Exclusive Performances, Videos & More
>http://faith.yahoo.com
>