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

20001128: Compressed NEXRAD products on NOAAPORT

Scott and Steve,

I have been working on enabling the display of the zlib compressed
nexrad imagery on NOAAPORT using the sample data currently being broadcast.

I uploaded nexz.tar.Z to the upc account on as2. This tarfile contains code I
have added to allow viewing of the zlib compressed NIDS/NEXRAD products 
in GEMPAK. I don't know if you will ever have the need to deal with the
compressed products on that end.

The changes to existing files are:

Added IFNEXZ = 6 to GEMPRM.PRM and gemprm.h as a new image type.

In gemlib/im/imsimg.f, I've added a check for products starting
with the FOS control character sequence (SOH cr cr nl).
If the product starts with the FOS characters, and the WMO id 
begins "SDUS5", then the product is tested to be a compressed
nexrad product and the header is read if possible.

In driver/active/xw/xsatim.c, added test for IFNEXZ and called gn/crnexz.c.

New routines-

gemlib/im/imnexrad.c:
        inflates the zlib portion and calls im_nihd2.f to read 
        the header.

gemlib/im/imnihd2.f:
        modified from imnihd.f to accept the data being passed
        in, instead of read from a file. Uses the IMGDEF.CMN/imgdef.h
        variable imprsz to set the offset from the start of the file
        to the start of the zlib compressed nids product.
        (this could be consolidated with the current imnihd.f if
        the current file reading were done is a separate calling routine).

driver/active/gn/crnexz.c:
        modified from crnids.c to inflate the zlib product and
        process using the unpacked data array.

I have included in the tarfile the zlib distribution for building zlib.a
under the $GEMPAK/source/zlib directory, as well as a test product
under gempak/source/gemlib/im/200011202122_N0RARX.nidz.

To enable reading of zlib products requires the linking of libz.a
to all the programs (and device drivers) which display imagery 
(same as was just done for the netcdf library for satellite images).

I can generalize the imnihd.f routine for being passed the data array
from the calling routine which opens the file for both compressed
and uncompressed images, as well as products from the NWS ftp server
which are uncompressed but have WMO and PIL headers on them. 
However, I haven't done this as of yet since I wanted to keep the 
modifications as separate as possible from the core code if you
don't want to deal with zlib.

The alternative of course is to inflate the data directly
from the LDM as a PIPE before storing on disk. I have a routine 
to do this as well (dcinflate), but given the volume of NEXRAD data, this
is probably less desireable than just FILE'ing to disk.

Since this compressed NEXRAD data will be available on NOAAPORT
starting Jan 1, I plan on adding zlib with the 5.6a patch
and releasing to the universities in the next week or so.

If you can tell me if you have any plans for zlib, then I can work
on making the detection of the various ways users will obtain the
data more robust. Currently, the nids images are expected to start
at byte 0 of the file without any header. The files on the NWS server
have the WMO and PIL, and the NOAAPORT products have the WMO and PIL
with the zlib portion containing the CCB, WMO and PIL as well.

  
Steve