20040416: 20040323: gpmap in pqact?

Gerry,

No ucar_logo.gif reference is in the source code...that is apparently an old
remnant of a Peter Neilly specific code mod.

FYI, bigfoot refuses my outside connection.

Steve Chiswell
Unidata User Support



>From: Gerry Creager <address@hidden>
>Organization: AATLT - Texas A&M University
>Keywords: 200404161858.i3GIwICT014070

>OK.  Mostly working, although I may be taking the hard path.  If you're 
>interested, a preliminary site is up at http://bigfoot.tamu.edu/radmap
>
>Question: The docs imply that putting a GIF with a logo in it in the 
>working directory will result in that being inserted in the image.  I've 
>tried, and failed.  Is there an incantation, or a chicken I'm missing?
>
>Now for watches and warning on http://mesonet.tamu.edu/currentwx.html
>
>Thanks
>Gerry
>
>Steve Chiswell wrote:
>> 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/msg04
> 460.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
>
>-- 
>Gerry Creager -- address@hidden
>Texas Mesonet -- AATLT, Texas A&M University   
>Cell: 979.229.5301 Office: 979.458.4020
>FAX:  979.847.8578 Pager:  979.228.0173
>Office: 903A Eller Bldg, TAMU, College Station, TX 77843
>
--
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publically available
through the web.  If you do not want to have your interactions made
available in this way, you must let us know in each email you send to us.