Hi Dan,
Thanks for the explanation, very helpful. Looks like if a test can be
made on the incoming file to check for 8 vs 4 bit, the "offset" which is
being affected by the line in the subroutine can be set properly.
______________________________________________________________________
Kevin Tyle, Systems Administrator **********************
Dept. of Atmospheric & Environmental Sciences ktyle@xxxxxxxxxxxxxxxx
University at Albany, ES-235 518-442-4578 (voice)
1400 Washington Avenue 518-442-5825 (fax)
Albany, NY 12222 **********************
______________________________________________________________________
On Thu, 13 Jan 2011, Dan Leins wrote:
Kevin,
The problem I'm having is that 6.2.0 (fresh build, no modifications) is not
properly displaying 4bit radar data. This was not a problem in my previous
version (5.11.1). I am making gif images using gpmap. The problem extends to
garp and nmap2 as well.
I download 4bit NIDS Level III data from the following site:
ftp://tgftp.nws.noaa.gov/SL.us008001/DF.of/DC.radar/DS.p19r0/SI.kcle/
I am able to view 8bit data without a problem. Those data are available here:
ftp://tgftp.nws.noaa.gov/SL.us008001/DF.of/DC.radar/DS.p94r0/SI.kcle/
Following the instructions in the previous email, I :
uncommented line 422 in $GEMPAK/source/gemlib/im/imsimg.f
make
ar rv /usr1/GEMPAK6.2.0/os/linux/lib/gemlib.a *.o
cd /usr1/GEMPAK6.2.0/gempak/source/programs/gp/gpmap
make
cp gpmap $OS_BIN
No errors noted during compile. When I re-run my script using this newly
compiled gpmap, the problem reverses. I get 4bit images, but no 8bit. Ugh!
See the attached images. (the timestamps are different, new data was arriving
as I was testing but I verified that the files were ok).
I noticed that the 8bit data has a header of:
SDUS51 KCLE 140254
N0QCLE
while the 4bit has a header of:
SDUS51 KCLE 140254
N0RCLE
Both N0Q and N0R have entries in my imgtyp.tbl file:
RADAR N0Q 0 255 11 2**32 1 upc_n0q256.tbl
RADAR N0R 0 105 11 2**26 1 leins_radimg.tbl
Very strange. Any ideas?
Thanks!
Dan
Kevin R. Tyle wrote:
Hi Dan,
Can you give a specific type of product that is causing the problem, as
well as a link to a source where one could download it (or, if it's
reasonably small, just attach it)? Your email mentions blank 4bit radar,
but the text of your email refers to blank 8bit radar.
I have found that VAD files do not display with 6.2 (using gpvad)
regardless of whether the line I referenced in the November 23rd GEMBUD
thread is commented out or not. I'm not surprised that there may be other
products that are not being parsed right.
Cheers,
Kevin
______________________________________________________________________
Kevin Tyle, Systems Administrator **********************
Dept. of Atmospheric & Environmental Sciences ktyle@xxxxxxxxxxxxxxxx
University at Albany, ES-235 518-442-4578 (voice)
1400 Washington Avenue 518-442-5825 (fax)
Albany, NY 12222 **********************
______________________________________________________________________
On Thu, 13 Jan 2011, Dan Leins wrote:
All,
I upgraded to GEMPAK6.2.0 and am now taking advantage of the ability to
display 8bit radar data. Since 8bit SRM doesn't appear to be available at
this point, I continue to download the 4bit version but am having trouble
viewing it in Garp/NMAP2/gpmap, etc...
It would appear this topic was covered about 2 months ago:
http://www.unidata.ucar.edu/mailing_lists/archives/gembud/2010/msg00273.html
I uncommented the line in question, recompiled, etc... and was able to
view
the 4bit Z/V/SRM data just fine. However the unintended side-effect was
that
I lost the ability to view all the other 8bit data.
Running gpmap verbosely gives the following error when trying to display
8bit Z data:
*
Enter <cr> to accept parameters or type EXIT:expecting bzip2 compression,
not found
[GEMPLT -48] NIMGFL - Can not open image file.*
Is there any way to compile gpmap to accept both 4bit and 8bit data?
Thanks,
Dan Leins
