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

20021101: how to dynamically generate McIDAS images in website (cont.)

>From: Sridharareddy Duggireddy <address@hidden>
>Organization: USF
>Keywords: 200210162107.g9GL7S107707 McIDAS web cgi-bin IMGDISP FRMSAVE


>   Thank you very much for your cooperation. I have understood your
>scripts. But i have some doubts. They are
>what will MCTABLE_WRITE and MCTABLE_READ do in mcidas?

MCTABLE_READ defines a list of McIDAS client routing table files to
use to determine which ADDE server will be used to fulfill a data request.
When you do a DATALOC LIST in McIDAS, the files in MCTABLE_READ are
searched to give you the dataset/machine name pairs you have defined
in your session.  I setup MCTABLE_READ to first use
.../htdocs/sridhara/mcidas/data/MCTABLE.TXT and then 
/home/mcidas/data/ADDESITE.TXT.  This setup follows the McIDAS installation 
instructions detailed

Unidata McIDAS-X HomePage
|_Installation and Configuration Version 2002
  |_Configuring Accounts
    |_Configure User Accounts

>In gen_mcidas_sat.csh
>what WILL  "EU=IMAGE" AND "EU=H20" do to the mcidas image?

The logic in gen_mcidas_sat.csh (adopted virtually in tact from the
examples that Jim Koermer provided) look at the ADDE dataset name to
see if the image is likely to be a Water Vapor (WV) image or not.
If the image is a Water Vapor image, then the H2O.ET enhancement is
used in the image display.  Otherwise, the IMAGE.ET enhancement is
used.  The reason that there is a difference is that the information
in water vapor images is contained in a much smaller brightness range
than for IR or VIS images.  The H2O.ET enhancement "colorizes" the
water vapor images to bring out the features in that smaller range
of brightnesses.

>what will "SU=IRTEMP" and "SU=H20TEMP" do to the mcidas image?

The selection of a stretch table (SU=) was done for the labeling of
the images with the BAR command.  If you play around with the display
created from the web page, you will see that the data BAR on the right
hand side shows different units for the different kinds of images, 
VIS, IR, and WV.

>In the last lines you wrote the following code
>   if(-e num_maps) then
>       set num=`cat num_maps`
>       @num+=1
>    else
>      set num=1
>    echo $ num > num_maps
>what did the above code do?

This is code that Jim included in his example.  It appears to be a
counter for how many times the page was accessed (the count is
incremented each time a GIF (tm) file is created).  I left this in the
script for you to use or ignore as you see fit.

>you have created the user nobody.

I did not create the user 'nobody'.  'nobody' was already a user.  It
is the user that is running the web server.

>where have you created this user i mean under which directory?

You should talk with Shelly about 'nobody'.  It is not a login account,
and its HOME directory is the same as for 'root', '/'.

>Is it necessary to place mk_mcsat under ..sridhara/mcidas/bin?

No.  This file can be put anywhere you like AS LONG AS it is in a
directory that has at least read and execute privilege for the user

>in mk_mcsat what will be the value in $HOME?

HOME will be inherited from its setting in gen_mcidas_sat.csh.  I set
HOME to tell McIDAS to create its temporary directory in
/usr/local/apps/php-apache/htdocs/sridhara/mcidas.  If you CD to that
directory and do a long list ('ls -alt'), you will see a directory
called .mctmp.  Each time McIDAS is run (and it is run each time a user
asks for the creation of a display of an image and its subsequent save
into a GIF file), it (McIDAS) creates a subdirectory under .mctmp.  In
this subdirectory, it creates a few files that are used for the
duration of that invocation of McIDAS.  When McIDAS exits (after the
'mcenv' invocation is over), the temporary directory under .mctmp and
all of the files in that directory are removed.

The way you had things setup, the .mctmp directory was located in '/'
and it was owned by 'root'.  What was needed was  to consolidate all of
the things that were happening into a single directory/directory
hierarchy that is owned by 'nobody'.  The way things were setup did not
follow this, and this was on of the problems being encountered that
prevented things from working.

>Thank You,

No worries.


NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly 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.