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

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

Jason,

>This is getting easier and easier...

I am very glad to hear this.  It really does mean that you have a firm
grasp of the concepts.  After this, everything else is "downhill".

re: adding additional comments

>Not at all... and from what you've said, I'm glad you did.

OK, I didn't want you to think that I was getting picky.  If you didn't
already know it, I must tell you that all support email transactions are
put into an inquiry tracking system to which everyone has access.  The
questions you ask and the answers you are given are then available to
new users who want to learn from others experiences.

re: WFSUB/... vs WF/SUB... being different datasets

>Thanks for pointing that out... I didn't catch it.  I meant to write
>WFSUB/051091...  Good thing you pointed that out before I (perhaps
>blindly) followed the directions in the e-mail in mcidas.

re: specifying the number of lines and elements in the second IMGREMAP

>But in the first IMGREMAP command I told it a size of 260 by 260... if
>I remap the VIS into that IR, it might not 'force' the size?

You are absolutely correct.  I wrote this section and then remembered
that the adding of SIZE was no only needed, it is rejected.

re: when to use IMGCHA

>Got it... so I wouldn't have to do an IMGCHA on the new IR image, just
>the new VIS image.

Exactly.

>Okay, on the new IR image WFSUB/051091IR.9 I wouldn't have to do a
>IMGCHA command.

Right.

>On the new VIS image WFSUB/051091VIS.9, I would have to do a IMGCHA
>command, but I would only have to change the band, time, and day... for
>example,
>
>IMGCHA BAN=1 DAY=91130 TIM=18:01:00

Right.

>And after all this, the images should be fine.

Yup.

>By the way, if I choose not to change the projection, the only thing I
>would have to do is change the first IMGREMAP (the command to the
>original IR image) to IMGCOPY and remove PRO=LAMB... correct?

Right.  You make a copy specifying the output size and section of the
original image you want in it (hence the term subsectioning).  The
pixels are copied exactly from the source to the destination (unless
you use MAG= to change this).

> Here's the first command I'm talking about:
>
>IMGREMAP WF/051091IR.19 WF/SUB051091IR.9 LAT=55 100 PLA=CENTER PRO=LAMB SIZ=26
> 0 260 MAG=1 RES=8

Or, it should be (following the discussion of WF/SUB... vs WFSUB/... above):

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

I removed the PLACE=CENTER keyword as it should not be there.  More on this
down below.

>If everything I said is true, then I think I've finally gotten this
>part.  Thanks so much...

No problem.

>I think I understand the DSSERVE and REDIRECT stuff you mention below,
>but I'm going to interpret it and send it in a separate e-mail.

Try playing with it some.  You will be using the commands:  REDIRECT
and DMAP to verify that things come from/go to the place you expect.

>From address@hidden Wed Oct 25 14:01:37 2000
>Subject: Re: 20001025: IMGREMAP: MAG= vs RES= (cont.)

re: PLACE= is not a IMGREMAP keyword

>Is it the default of the IMGREMAP command that the Lat and long you
>give it go in the upper left, or is it the center?

Actually, you specify the projection through the PRO= keyword.  For LAMB,
the positional parameters for PRO= are:

  PRO=DEST | use the navigation of ddataset (def)
     =LAMB slat1 slat2 slon | Lambert Conformal, standard latitude
                              and standard longitude (slat1 def=30,
                              slat2 def=50, slon def=center longitude)

The LAMB PRO= setting is:

PRO=LAMB slat1 slat2 slon

You specify the Lambert Conformal projection with 'slat1', 'slat2', and
'slon'.  'slon' is specifying your center longitude.

re: adjusting your LAT= keyword values to put the image where you want it

>Okay.  I was guessing on the upper lat and long a little bit.  I'll
>make sure I pay attention to that once I start pulling sub-sets of the
>images.

The thing to do is try a set of values; display the resultant image; and
then adjust.

>I'm also concerned about running the program on 'modified' data (from
>changing the projection).  I suppose I could not change the projection,
>run the program, and then extract the info I need with IMGPROBE

Right.

>... and
>then bring in into arc/info (which has been my intention all along; to
>bring it in arc/info).

I knew this from previous discussions.

>If I knew the original projection of the
>satellite image, and arc/info supports this projection, I could
>reproject the data outside of mcidas, minimizing any effects.  Do you
>know where I would find that information?

The navigation model for the GOES-Next platforms (e.g., GOES-8 ..
GOES-11) is quite complex.  I seriously doubt whether ArcInfo supports
it.  The projection in METEOSAT images, on the other hand, is a simple,
idealized satellite projection.  There is a chance that ArcInfo would
understand this.  If it does, you could remap your images using the
TOPO/QUAD (AREA9019) image in the Unidata McIDAS-X distribution.  This
was created from a METEOSAT image so its navigation is simple (METEOSAT
images have been remapped into an idealized satellite projection).

>Thanks so much... I promise that I'm almost out of questions to ask.

Asking questions is no problem.  I will become more unavailable soon
as I am holding a McIDAS training workshop starting on Monday.

Tom