This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
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