NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Hi all,With line 422 of imsimg.f commented out, I can display *both* 4- and 8-bit base reflectivity issues as long as the source is Unidata's Internet Data Distribution (IDD) data stream. The difference appears to be that in the IDD stream, a 3-digit sequence number, followed by a blank space, two control characters, and a "carriage return" appear before the WMO header which begins with "SDUS", but this does not appear in the file that sits on the tgftp file server. I believe that the "sequence number" is a legacy from the old Family of Service (pre-NOAAport) data feed, but which is included in the IDD for compatibility with the LDM.
I suspect that a modification of IM_SIMG which checks for the existence of the "sequence number" set of characters would eliminate the problem with displaying products from the tgftp site.
However, I think more issues still exist with some other radar files, such as the VAD products, which as I mentioned, do not display in 6.2.
--Kevin On 01/14/2011 03:54 PM, Dan Leins wrote:
Jeff,That was my initial thought too, I also figured why do I need 4bit data at all when I have 8bit? Then I realized that there is no 8bit SRM product available (nor will there be based on what I found out from NWSHQ, 4 bit SRM will continue to be distributed and not terminated). So it would seem that while I can view hi-res Z/V data, I'm stuck w/ lo-res SRM. Hence the problem. I've been using examples of reflectivity in this thread since I can do an apples-to-apples comparison between the two, but the goal of fixing this is rooted in the 4bit SRM product.Dan Jeff Lake - Admin wrote:or just be patient ... a huge chunk of 4 bit was removed on Tuesday, it won't be long and all 4 bit will be goneFor a quick "fix" while you're waiting for a slicker programming fix as suggested by Kevin, how about compiling both versions and saving the executables with different names -- gpmap and gpmap_4bit? Doesn't help for nmap and garp.Quoting Dan Leins <theedge981@xxxxxxxxx>:Kevin,The problem I'm having is that 6.2.0 (fresh build, no modifications) isnot 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 troubleviewing 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 thatI lost the ability to view all the other 8bit data.Running gpmap verbosely gives the following error when trying to display8bit 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==================================================================== Clinton M. Rowe Professor Meteorology/Climatology Program phone:(402)472-1946 Earth & Atmospheric Sciences fax:(402)472-4917 University of Nebraska-Lincoln crowe1@xxxxxxx _______________________________________________ gembud mailing list gembud@xxxxxxxxxxxxxxxxFor list information or to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/_______________________________________________ gembud mailing list gembud@xxxxxxxxxxxxxxxxFor list information or to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/_______________________________________________ gembud mailing list gembud@xxxxxxxxxxxxxxxxFor list information or to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/
gembud archives: