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

Re: 20040323: gpmap in pqact?



Gerry,

see the README file in $GEMPAK/source/contrib/tdl/radmap
(you can ignore info on compiling since that is part
of the GEMPAK build).

Also info in the archives such as:

http://www.unidata.ucar.edu/projects/coohl/mhonarc/MailArchives/gempak/msg04460.html

>From a web cgi, I run a script that takes the user input for the station
selected, finds the most recent radar file for that site, and then runs
radmap_sw -s {input radar file} {output_file} {titlestring}

The output file is a unique temporary file name, and once the file is
created, it is catted to the browser with the
imagetype/gif and size and then removed, so that these files don't 
build up and let web users cause space problems.

Steve Chiswell
Unidata User Support


On Wed, 2004-03-24 at 06:05, Gerry Creager N5JXS wrote:
> Looks like I'm unable to find the instructions on using radmap_sw as a 
> cgi program.  Is there a ready pointer to documentation?
> 
> If not, I can try to slog thru it tomorrow or Fri.
> 
> Thanks,
> Gerry
> 
> Steve Chiswell wrote:
> > Gerry,
> > 
> > As has already been pointed out, I did post a script for EXEC from pqact
> > that employs a load balancing file lock that allows one process at a
> > time. It will get the job done, and will protect against falling
> > behind of restart from an outage or queue remake.
> > 
> > I'd recommend against piping to a script for generation directly since
> > when you first start up an LDM with an empty queue, you will get a slug
> > of 1 hour's worth of NEXRAD products in short sequence. You would either
> > have several hundred instances of a generation script running, or
> > several hundred scripts waiting for PIPE input. The EXEC action
> > following the FILE action allows you to separate the generation action.
> > It also allows you to control your logic for scenarios when generation
> > may be falling behind.
> > 
> > Other alternatives are:
> > 
> > 1) Use the 1km radar mosaic GINI and create regional sectors which are 
> > fewer than the number of NEXRAD sites (eg from SECTOR or GPMAP).
> > 
> > 2) Use a cgi type of web script for on demand access (which may
> > eliminate the need to draw lots of boring images at the expense of
> > drawing some multiple times). An example using the radmap_sw gempak
> > program is available at:
> > http://motherlode.ucar.edu/unidata/images/nids/
> > The cgi for the above will create the gif file, and then cat it to the
> > browser using an image/gif type for the page.
> > 
> > Steve Chiswell
> > 
> > On Mon, 2004-03-22 at 20:57, Gerry Creager N5JXS wrote:
> > 
> >>Is there any way to pipe the incoming nexrad Level III data to gpmap in 
> >>pqact, if one is doing individual sites, so that a system isn't taken to 
> >>its knees every time a cron job fires that looks at every site?
> >>
> >>Seems that if we could pipe it, we could spread out the load.  Or, am I 
> >>missing something fundamental?
> >>
> >>Thanks!
> >>Gerry