Re: nex2image and displaying output in NCEP N-AWIPS

Gregg,

Here is a quick pipe program to flip the 99 in to 10 (goes 7),
which will be treated as ID=33 in imgtyp.tbl:

--------------------giniid.c----------------------
#include <stdio.h>
#include <unistd.h>

main()
{
int isinit=!0;
size_t nbytes;
unsigned char buf[8192];

while ( ( nbytes = read(STDIN_FILENO, buf, (size_t)8192) ) > 0 )
   {
   if ( isinit )
      {
      if ( buf[22] == 99 ) buf[22] = (unsigned char)10;
      isinit = 0;
      }
   write(STDOUT_FILENO, buf, nbytes);
   }

}

----------------------------------------------------------
run the program as: cat inputgini | giniid > output gini

I can now plot the image using the imgtyp.tbl entry:
RADAR                N0R           0    105     33  2**26      1 upc_rad24.tbl

Steve Chiswell
Unidata User Support


On Wed, 2006-02-15 at 14:56, Gregory Grosshans wrote:
> Steve,
> 
> Do you know if its possible to manually/easily change the satellite ID 
> in the AREA file to a "known" number, like GOES-7,
> so SPC can see what the image looks like? 
> 
> Thanks,
> Gregg
> 
> Steve Chiswell wrote:
> 
> >Gregg,
> >
> >OK...bummer....
> >
> >In nex2gini, I define the gini satellite ID as 99 to not conflict with
> >the defined GOES satellite numbers. In gemlib/im/imgi2gm.f, the
> >routine has a set of IF statements:
> >C
> >C*      Set the satellite number. (Octet 2)
> >C*
> >Where I added 
> >          ELSE IF ( isat .eq. 99 ) THEN
> >            imsorc = 11
> >
> >
> >This all has to do with mapping the GINI satellite ID to the AREA file
> >satellite ID used in imgtyp.tbl. Its ugly already since GINI files
> >don't use the same numbers as the AREA files do.
> >
> >So, to use NCEP's distribution, out of the box, we would have to
> >modify my nex2gini code to use one on the "known" numbers like
> >GOES-7 (which isn't broadcast currently, or work with NCEP to modify
> >that routine.
> >
> >Sorry about that!
> >
> >Steve Chiswell
> >Unidata User Support
> >
> >
> >On Wed, 2006-02-15 at 13:54, Gregory Grosshans wrote:
> >  
> >
> >>Steve,
> >>
> >>I've updated imgtyp.tbl with the information you provided below and
> >>have the upc_rad24.tbl file in the local directory.  I reset SAT and
> >>RAD to the current directory, made a subdirectory call "N0R" and
> >>placed the image file in the "N0R" directory.
> >>
> >>In NMAP2 the image appears in the timeline but the following error is
> >>in the "Error Message" window:
> >>
> >>[IM 1} No image type entry for file $RAD/N0R/N0R_20060215_2015
> >>[GEMPLT -60] NIMCORD - Invalid image display coordinates
> >>[IM 1} No image type entry for file $RAD/N0R/N0R_20060215_2015
> >>
> >>The above error occurs when trying to load the image as a "SAT"ellite
> >>image and also as a "RAD"ar image.
> >>
> >>Am I overlooking something that is causing this error?
> >>
> >>Thanks,
> >>Gregg
> >>
> >>
> >>
> >>Steve Chiswell wrote: 
> >>    
> >>
> >>>Gregg,
> >>>
> >>>Attached is a 1km GINI as uncompressed. I do have another
> >>>addition to nex2image which writes the image portion as a png which
> >>>I added code to crgini.c to handle...but since that is configurable
> >>>on creation side, that wouldn't prevent you from using NCEP's
> >>>distribution for uncompressed GINI's.
> >>>
> >>>As for the NetCDF grids for QPESUMS, they are very similar to the
> >>>file structure for the AWIPS NetCDF images that is already handled
> >>>in the IM_library, so I made a few additions there as you note.
> >>>
> >>>At any rate, I have the following lines in my $GEMTBL/sat/imgtyp.tbl
> >>>file:
> >>>
> >>>! Unidata GINI composite RADAR (ranges as defined in unidata/nex2gini.tbl)
> >>>RADAR                N0Z           0    255     11  2**24      1 
> >>>osf_ref16.tbl
> >>>RADAR                NET           0    255     11  2**25      1 
> >>>upc_net.tbl
> >>>RADAR                N0R           0    105     11  2**26      1 
> >>>upc_rad24.tbl
> >>>RADAR                NCR           0    105     11  2**27      1 
> >>>upc_rad24.tbl
> >>>RADAR                NVL           0    255     11  2**28      1 
> >>>upc_nvl.tbl
> >>>RADAR                N1P           0    255     11  2**29      1 
> >>>upc_n1p.tbl
> >>>RADAR                NTP           0    255     11  2**30      1 
> >>>upc_ntp.tbl
> >>>
> >>>I've attached the upc_rad24.tbl file as well. If you place the images
> >>>under the $SAT duirectory for nmap, you can take advantage of more
> >>>than the 20 radar colors that GEMPAK uses for radar images!
> >>>
> >>>Steve Chiswell
> >>>Unidata User Support
> >>>
> >>>
> >>>
> >>>
> >>>On Wed, 2006-02-15 at 12:58, Gregory Grosshans wrote:
> >>>  
> >>>      
> >>>
> >>>>Steve,
> >>>>
> >>>>Would it be possible for you to send an attached 1km GINI radar mosaic 
> >>>>that I can try to display in NCEP
> >>>>NMAP2?  If this works then SPC can decide if we want to create the 
> >>>>mosaic here via the nex2image code
> >>>>or possible obtain it via LDM in a non-operational manner.  The nice 
> >>>>thing about this is NCEP NMAP
> >>>>can display the data.  The QPESUMS NetCDF data I suspect doesn't display 
> >>>>in NCEP NMAP.
> >>>>
> >>>>Thanks for your help.
> >>>>Gregg
> >>>>
> >>>>Steve Chiswell wrote:
> >>>>
> >>>>    
> >>>>        
> >>>>
> >>>>>Gregg,
> >>>>>
> >>>>>The calibration bar units would be the only thing that the NCEP
> >>>>>distribution doesn't have. I can send you the 1km GINI radar files
> >>>>>      
> >>>>>          
> >>>>>
> >>>>>from our LDM if that would be of use for you.
> >>>>    
> >>>>        
> >>>>
> >>>>>However, you may want to investigate the 1km products that NSSL
> >>>>>is working to produce (Ken Howard and Steve Vasiloff provided some
> >>>>>background to their QPESUMS product to us last year). I did modify
> >>>>>our GEMPAK distribution to read their NetCDF tiled files-
> >>>>>and hoping that they were going to produce single files rather than
> >>>>>tiles. The point here being that they are doing the 3-D volume level 2
> >>>>>radar data, and the AP/clutter removal). See the March 2005 and
> >>>>>May 2005 links at:
> >>>>>http://www.unidata.ucar.edu/community/seminars/
> >>>>>
> >>>>>We are hoping to be able to distribute the QPESUMS products when they
> >>>>>are ready...but I haven't heard an update on the status recently.
> >>>>>
> >>>>>Steve Chiswell
> >>>>>Unidata User Support
> >>>>>
> >>>>>
> >>>>>On Tue, 2006-02-14 at 14:31, Gregory Grosshans wrote:
> >>>>> 
> >>>>>
> >>>>>      
> >>>>>          
> >>>>>
> >>>>>>Hi Steve,
> >>>>>>
> >>>>>>I was talking to Scott today and heard you stopped by NCEP last week. I 
> >>>>>>hope your visit went well.
> >>>>>>
> >>>>>>There is renewed interest at the SPC in 1km radar mosaics. Some time 
> >>>>>>ago 
> >>>>>>through email exchanges with you it
> >>>>>>appeared things would work except for the calibration bar from the GINI 
> >>>>>>data in the N-AWIPS core code (i.e. see email
> >>>>>>below).
> >>>>>>
> >>>>>>Can you tell me if this would still be the case, that is if we were to 
> >>>>>>run nex2image to create a 1km mosaic from
> >>>>>>level-III radar products and then displaying the GINI data in NCEP 
> >>>>>>N-AWIPS (i.e. NMAP2)? Are you aware of
> >>>>>>any other limitations that may result from running the nex2image 
> >>>>>>program 
> >>>>>>with the rest of the N-AWIPS being
> >>>>>>core NCEP code?
> >>>>>>
> >>>>>>Thanks,
> >>>>>>Gregg
> >>>>>>
> >>>>>>Steve Chiswell wrote:
> >>>>>>
> >>>>>>   
> >>>>>>
> >>>>>>        
> >>>>>>            
> >>>>>>
> >>>>>>>Gregg,
> >>>>>>>
> >>>>>>>You can get the distribution via the web. If you are running Linux,
> >>>>>>>then the easiest way would be to grab the binary and take the programs
> >>>>>>>     
> >>>>>>>
> >>>>>>>          
> >>>>>>>              
> >>>>>>>
> >>>>>>>from bin/linux. Also, you will need the $GEMTBL/unidata directory for
> >>>>>>   
> >>>>>>
> >>>>>>        
> >>>>>>            
> >>>>>>
> >>>>>>>nex2image to place the appropriate platformID and calibration numbers 
> >>>>>>>in
> >>>>>>>the GINI header (Also grab the entries from $GEMTBL/sat/imgtype.tbl and
> >>>>>>>the color enhancements from $GEMTBL/luts mentioned in the imgtype.tbl 
> >>>>>>>file).
> >>>>>>>
> >>>>>>>With NCEP's plotting, you won't get a calibration bar from the GINI.
> >>>>>>>Our distribution has additional code to create read the calibration
> >>>>>>>section from the GINI.
> >>>>>>>
> >>>>>>>Steve Chiswell
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>     
> >>>>>>>          
> >>>>>>>              
> >>>>>>>
> >>>>>>______________________________________________________________
> >>>>>>! upc_ref24.tbl
> >>>>>>!
> >>>>>>! Color table for 24-level NIDS Reflectivity
> >>>>>>!
> >>>>>>!Color name    Abrev   Red  Green   Blue  X color name
> >>>>>>                         0      0      0
> >>>>>>                         0      0     00
> >>>>>>                         0      0     00
> >>>>>>                         0      0     00
> >>>>>>                         0      0     00
> >>>>>>                         0      0    000
> >>>>>>                         0      0    020
> >>>>>>                         0      0    040
> >>>>>>                         0      0    060
> >>>>>>                         0    236    236
> >>>>>>                         1    160    246
> >>>>>>                         0      0    246
> >>>>>>                         0    255      0
> >>>>>>                         0    200      0
> >>>>>>                         0    144      0
> >>>>>>                       255    255      0
> >>>>>>                       231    192      0
> >>>>>>                       255    144      0
> >>>>>>                       255      0      0
> >>>>>>                       214      0      0
> >>>>>>                       192      0      0
> >>>>>>                       255      0    255
> >>>>>>                       153     85    201
> >>>>>>                       255    255    255
> >>>>>>            
> >>>>>>