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

20010806: 20010805: Problems at UPRM (cont.)

>From: Unidata Mcidas Account <address@hidden>
>Organization:  University of Puerto Rico
>Keywords:  200106202036.f5KKab115440 McIDAS ADDE DATALOC DSINFO IMGLIST


>   Everything seems to be working perfectly.  I was able to run without
>any problems all the commands you had sent me earlier.  I also was able to
>display images from the GINI sets.

Sounds good.

>I just have two more questions.
>   The first question relates to the image archiving I'm planning on
>doing.  You had explained about area files and png's, and how to archive
>images that I had already downloaded via LDM from the unidata stream.  I
>wanted to know the most efficient way of archiving images that are
>received via ADDE, which are requested and downloaded every time I try to
>imgdisp them, right?

When you IMGDISP an image, it is only displayed in the frame you are
displaying.  It is not automatically copied to a disk file.  In order
to copy to a disk file, you need to use IMGCOPY.  Before doing this,
you will need to have setup an ADDE dataset into which you can copy
the images.  The standard McIDAS installation directs sites to setup
a dataset called MYDATA which has IMAGES as a descriptor.  The MYDATA/IMAGES
dataset is designed to allow access to all images in AREA file format.
To test to see if you have setup MYDATA, run:


If you do not see a MYDATA/IMAGES entry, then run:


Once you have a local dataset like MYDATA/IMAGES that you can write to,
you can copy the images you want like:


Before doing this, you must be aware that this will write to AREA file
2000 (AREA2000) since the setup of MYDATA/IMAGES is a one-to-one
mapping between dataset position and AREA file number.  If you
already have an AREA2000 file, it will be overwritten, so you need
to make sure that this is OK with you before doing the IMGCOPY.

Once the data is in an AREA file, you could use area2png to compress
it before you save it in your archive.

>Also, I'd like to know if there's somewere I could
>find information about how often the images in each set were refreshed.
>I tried the <imglist xxx form=exp> command but I found nothing relevant

This listing will tell you the time of each image, so you can see how
often the images are created.  It does not tell you when those images
are available, however, since that is a function of when they are
broadcast on NOAAPORT and/or when they are conveyed to a site by the

>   My second question is about the f-key menu.  It's still not working.  I
>know there are images in the sets that I'm trying to access with it, but I
>always get the same error.
>EG: Invalid Frame number.
>EG: first positional argument is too big --> 11
>EG: Must be valid 'Frame number' integer value within range 1 thru 1.
>EG failed, rc=1
>   If I replace the elevens with ones it works fine.  Is this because it's
>trying to access the eleventh image in a set where there's only one?  How
>can I fix this?

The default settings for McIDAS sessions are controlled by the file
.mcidasrc.  The first time a McIDAS session is run, this file will be
created in you HOME directory (e.g., ~mcidas).  Since your session is
only starting up with one frame (a strange thing, by the way), it
is most likely that there is a line like:

-f address@hidden

in your ~/.mcidasrc file.  You have two options here:

o edit .mcidasrc and change the entry to be -f address@hidden
o delete ~/.mcidasrc and rerun 'mcidas' to force .mcidasrc's recreation

The second option will rely on the fact that the default setup in the
.mcidasrc file is for 17 frames that are 480x640 in size.  If you
would like larger frames for displaying data, then change the 480x640
part to something larger.  I routinely use 600x800.  The Fkey
menu defaults for loading images expects frame sizes of 480x640
so things will not be centered nicely if you change your frame sizes.
The new MCGUI that I am including in my McIDAS-X 7.80 release takes
a different approach to loading images thereby allowing users to
use whatever size frames they like.

>I was going to try to edit the UNIDATA.MNU file, but I
>decided to ask first, since while reading through it I noticed the frame
>number was a variable.

Do not edit UNIDATA.MNU unless you are really adventerous.

>   Thank you once again.

By the way, the new 7.80 release is now out in our FTP area.  You should
consider upgrading to it before you go too much further.  The upgrade
will save you from a number of headaches.

**************************************************************************** <
Unidata User Support                                    UCAR Unidata Program <
(303)497-8644                                                  P.O. Box 3000 <
address@hidden                                   Boulder, CO 80307 <
---------------------------------------------------------------------------- <
Unidata WWW Service                        http://www.unidata.ucar.edu/      <
**************************************************************************** <

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.