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

20001024: IMGREMAP: MAG= vs RES= (cont.)

>From: Jason Allard <address@hidden>
>Organization: PSU
>Keywords: 200010240345.e9O3jC425238 McIDAS-X IMGREMAP MAG RES

Jason,

>I think I have a handle on it now (at least this part). Just to
>confirm, here's what I intend to do.

OK, ready.  I hope that you won't mind me adding small, editorial
comments throughout the reply.  You have the big picture in hand,
but I want to "dot the Is" and "cross the Ts" as it were :-)

>I've got a group VIS images
>(WF/051091VIS) and a group of IR images (WF/051091IR).  The VIS are in
>AREAs 2384-2396 (as defined by the dsserve command) and the IR are in
>AREAs 2360-2383 (also as defined by the dsserve command).  So, 13 VIS
>images and 24 IR images.

Excellent.

>I'm only going to perform the transformation
>on images between 12:00 and 22:00 UTM (7am and 5pm EST).  The 18:00 UTM
>images would be WF/051091VIS.8 and WF/051091IR.19.   Let's assume that the
>resolution of the VIS is 4km and the IR is 8km.

Very good.

>The first thing I
>would do (since I want it in a lambert's projection) is convert the IR
>image with the command:
>
>IMGREMAP WF/051091IR.19 WF/SUB051091IR.9 LAT=55 100 PLA=CENTER PRO=LAMB SIZ=26
> 0 260 MAG=1 RES=8
>
>I wouldn't really need to do RES=8 since it's already 8km, but I guess
>it can't hurt.

Actually, you _do_ want to include the RES=8 keyword and value.  The reason
is that the default for RES= for IMGREMAP is RES=1:

  RES= | resolution of ddataset in km; not valid with PRO=DEST (def=1)

The (def=1) means that the default is RES=1.  Since this is not what you
want, you should specify RES=8.

>However, would I need to use the DSSERVE command before
>this to link up the new image with an area?

Yes.  What one does with DSSERVE is associate an ADDE dataset name and
descriptor with a set of data files.  In your case, you have already
associated the name WF and descriptor 051091IR with the set of images
in AREA file format with AREA2360..AREA2383, inclusive.  Similarly, you
have associated the set of images in AREA2384..AREA2396 with the ADDE
group WF and descriptor 051091VIS.

Your IMGREMAP command is saying to take the 19th element of WF/051091IR
and remap it into the 9th element of WF/SUB051091IR.  In order to do
this, you would have to have first setup the meaning of WF/SUB051091IR.

>Assuming this is true, I'd have to do these steps first:
>
>DSSERVE ADD WFSUB/051091IR AREA 6000 6011

Here you are setting up a dataset whose name is WFSUB and descriptor
is 051091IR.  Your IMGREMAP command suggests that you wanted to
do the remap into the same WF dataset but into the SUB051091IR
descriptor.  You have to either change your IMGREMAP command above to
something like:

IMGREMAP WF/051091IR.19 WFSUB/051091IR.9 LAT=55 100 PLA=CENTER PRO=LAMB SIZ=260 
260 MAG=1 RES=8

OR

if you really want to keep using the WF dataset, you need to change your
DSSERVE invocation:

DSSERVE ADD WF/SUB051091IR AREA 6000 6011

>and
>
>DSSERVE ADD WFSUB/051091VIS AREA 6012 6022

The same comment immediately above holds for the VIS images.

>After the DSSERVE commands and that IMGREMAP command, I'd want to make
>a copy of the IR image with:
>
>IMGCOPY WFSUB/051091IR.9 WFSUB/051091VIS.9 SIZE=ALL
>
>The WFSUB/051091VIS.9 image will be where I IMGREMAP the corresponding
>VIS image.  I called the copy WFSUB/051091VIS.9 (note the VIS in the
>name) because this will be where the VIS image will go (I know this
>could get confusing, but I'll just have to pay attention).

Right.  This makes sense.

>I would
>then IMGREMAP the original VIS image into the copy of the IR image
>with:
>
>IMGREMAP WF/051091VIS.8 WFSUB/051091VIS.9

The only concern at this point is the specification of the output image
size (number of lines and elements).  To be "safe", I would first list
the information for the IR copy:

IMGLIST WFSUB/051091VIS.9 FORM=EXP

For sake of argument, let's assume that this size is 520 lines and 716
elements (I selected these numbers at random; pleae do not place
any importance on their values!!).  Now, specify the size on the
IMGREMAP invocation:

IMGREMAP WF/051091VIS.8 WFSUB/051091VIS.9 SIZE=520 716

>At this point, my subsetted images are in WFSUB/051091IR.9 and
>WFSUB/051091VIS.9

Right.

>...  these images cover the same physical area, have
>the same resolution, and are co-located.  Basically everything I
>wanted, correct?

Yes, exactly.

>The only thing to do now is perform the IMGCHA command on both images.

Wait (this may sound like back peddling, but please bear with me).  My
original comments about needing to do an IMGCHA apply to situations
where one is remapping into an image that already exists.  When
you create a new image using IMGREMAP (your top example of specifying
PRO=, for instance), you do not need to do this.

Now, in the next step where you remap your VIS image into the copy
of the IR you made, you _do_ need to do this.

>Is all the information lost, or do I only have to define some things?

The information you need is in the original images, so it is not
lost.  The information for the WFSUB VIS image is in WF/051091VIS.8;
the information for the WFSUB IR image is in WF/051091IR.19.

>For example, if I did an IMGLIST on the image, would it know the center
>lat and lon and the band?

It would know the center lat and lon, but the BAND information would
be wrong.

>Would all I have to add with the IMGCHA
>command be the date, time, and resolution?

The resolution should be fine, but the date and time might be wrong.

>One other question I have concerns the DSSERVE commands I made
>earlier.  How does mcidas know where to put the new images created.

Only if you "tell" it.

>With the DSSERVE command it knows what AREA to put them in, put in what
>physical location (i.e., hard drives) is the image stored?

McIDAS uses two facilities to locate data files: REDIRECT and MCPATH.

REDIRECT specifies the location of a file or group of files that are
identifiable by a regular expression.  For example, if you have a
set of files named AREA2001 - AREA2099 in a directory called /var/data,
you could "tell" you McIDAS session to look in /var/data when trying
to access those files (read/write/create/delete, etc.):

REDIRECT ADD AREA02* "/var/data

MCPATH, on the other hand, is an environment variable that defines a
list of directories which McIDAS searches when looking to read or
write files.  The directories in MCPATH are separated by colons and
are searched from left to right.  When McIDAS goes to write a file
for which there is no REDIRECTion (REDIRECTions take precedence over
MCPATH), it will use the first directory in your MCPATH in which
you have write permission.

The weak point about MCPATH is that you may have a directory that
has a data file of a certain name (e.g., AREA2369) in one of your
MCPATH directories that has read/write permission set so that you
can't write it.  In this case, your write operation (like IMGREMAP)
will fail.  One gets around this by specifying REDIRECTions for
files in directories that you can read from and write to.

So, your example above was to put the remapped VIS data into AREA
files that range from 6012 to 6022.  You should then setup a REDIRECTion
in your McIDAS session that tells McIDAS where to find those files.

File REDIRECTions are persistent from session-to-session.  Once you define
a REDIRECTion, you don't have to define it again.

One other comment about REDIRECTions.  McIDAS will use the most specific
REDIRECTion that you have defined to locate a file.  Here is an example:

suppose you defined two REDIRECTions:

REDIRECT AREA6*  "/home/jason/mcidas/data
REDIRECT AREA61* "/var/data/mcidas

further suppose that there is an AREA file called AREA6123 in both
/var/data/mcidas and /home/jason/mcidas/data, and you went to delete the
AREA file AREA6123 from your (you being jason) mcidas/data directory:

LWU DEL AREA6123

will delete the file /var/data/mcidas/AREA6123 IF you have read/write
permission for the file and the directory /var/data/mcidas.

Please refer to the online help for REDIRECT for more information on
how REDIRECTions can be used.

>Thanks so much for the help, it's greatly appreciated.  It all seems so
>simple now that you've explained it.

Once the big picture can be seen, the details start falling into place.

Tom