This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
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