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

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

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


>This seems to make sense... I have a lot of images (original), images that
>will be sub-setted (with IMGREMAP command) and those images that I'll run
>the program on that will create new AREAS.  I suppose I'll have to manage
>this closely. 

Yes, you will need to make sure that there is no name clash with output
AREA file numbers.

>Just a little background... I have images (original) that I have divided
>up into three classes based on upper air winds:  best weak flow, weak flow,
>and strong flow (that is, progressively stronger 500mb winds).  Perhaps it 
>would be best to create three REDIRECT files to manage this:
>REDIRECT ADD BEST* "/fractal/s2/allard/mcidas/best
>REDIRECT ADD WEAK* "/fractal/s2/allard/mcidas/weak
>REDIRECT ADD STRONG* "/fractal/s2/allard/mcidas/strong
>where BEST is best weak flow; WEAK is weak flow; STRONG is strong flow; and
>/fractal/s2/allard/mcidas is a directory I created to manage the AREA files.

REDIRECT is used for McIDAS data files, not for ADDE datasets.  The
REDIRECTions you list would tell McIDAS to locate files named BEST*, WEAK*,
and STRONG* in the various directories.  I think that what you are after
is to segment the data files by class of wind flow.  For this, you would
create ADDE datasets.  The first step is to identify image file numbers
that will be used for each.  Perhaps, this would look like:

AREA7000 - AREA7099 -> BEST
AREA7100 - AREA7199 -> WEAK
AREA7200 - AREA7299 -> STRONG

Now, define datasets that reflect this segmentation:

DSSERVE ADD WINDS/BEST AREA 7000 7099 "Best weak flow
DSSERVE ADD WINDS/WEAK AREA 7100 7199 "Weak flow
DSSERVE ADD WINDS/STRONG AREA 7200 7299 "Strong flow

>When I'm working with weak flow day images, I'll only keep the WEAK* redirect
>active so that if I have the same AREAs in all three directories, it only
>reads and writes from the /fractal/s2/allard/mcidas/weak directory.

Again, the REDIRECTions are used for the data files themselves.  In your
case, this the AREA files.

>Mentally, I can assign (and later physically assign with the DSSERVE command)
>AREAS 1-3000 to the original images, AREAs 3001-6000 to the sub-setted images,
>and AREAs 6001-9000 to the images on which I ran the program.


>For example, the 051091VIS images and the 051091IR images (that we've been
>discussing) are weak flow days.  I can make only that redirect active with:

No, not quite.  The 'REDIRECT REST' invocation tells McIDAS to read a series
of REDIRECTions from a file.  The invocation:


would mean to read a set of REDIRECTions from the file WEAK.NAM.

>Now, I'll re-assign new AREAs for my original data (I didn't have that many
>assigned yet, so this is no big deal):
>And then, preparing for the sub-setted images, I'll do:
>DSSERVE ADD WFSUB/051091IR AREA 3014 3037

OK.  I recommend to add the quote field at the end to help you remember
what you were doing later.  The quote field is used for informational
purposes so that a 'DSINFO I WFSUB' done later gives back a nice, annotated

>Now, when I do the IMGREMAP command, mcidas will write the new images created
>(both the AREA file and the actaul image) into /fractal/s2/allard/mcidas/weak 
>because that is the only active redirect.

If the REDIRECTion is for the AREA files in question, then that is correct.

>Once I'm done with weak flow days
>I can clear the redirect, restore best or strong and perform those functions
>for those images without worrying about having similar AREAs because only
>one redirect is active.  If I'm correct about all this, then I'm golder with
>the REDIRECT and DSSERVE commands.

Try playing with REDIRECTions to get the feeling of them.  For grins, do
the following from a McIDAS-X session:

REDIRECT ADD AREA6* "/fractal/s2/allard/mcidas/weak
DSSERVE ADD TEST/IMAGES AREA 6000 6999 "A test dataset composed of AREA files


Then, from your Unix session, run:

ls /fractal/s2/allard/mcidas/weak

What do you see?

>Thanks once again... I currently can't think of any relevant questions to ask.
>imagine that.


>From address@hidden Wed Oct 25 15:27:34 2000

re: After this, everything else is "downhill".

>That's what I'm afraid of...

I am afraid that you misunderstood.  I meant everything will get easier
and easier, like going downhill after struggling up.

re: me being picky

>No, I didn't think you were being picky, I'm glad your paying so much attention
>to the details.


>>  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.

>Am I correct with the first statement, or the second?  Basically, it will force
>the size so that I don's need to do the SIZE command?

When you IMGREMAP into an existing file, the number of lines and elements
(i.e., the size) are already set; they will not be changed.  

When you IMGREMAP into a new file and, therefore have to specify the PRO=
you want in the output image, you must tell McIDAS the size of the output.

>Concerning your statement about MAG= you made about 10 lines above...
>the IMGREMAP command has MAG=1 in it... doing this will keep the pixels
>copied in exactly the same location from the source to the

MAG= is a keyword that manipulates how the pixels from the original image
are selected:

MAG=-2 - every other pixel from the original is used in creating the output 
MAG=1 - every pixel from the original is used in creating the output image
MAG=2 - every pixel from the original is used twice in creating the output image

>a different MAG will change this... hence, I only want to use MAG=1?

You only want to use MAG=1, yes.

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

>Okay, so the center of the image in the slon I give in and with a size of 250
>it'll go 250 lines above and below that line of longitude?

If you specify that there are 250 lines, then there will be 125 above and
125 below for a total of 250.

>How does it know
>where along that center longitude to start drawing the image?

The Lambert Conformal projection is totally specified by the 'slat1',
'slat2', and 'slon' parameters.  The image projection is totally specified
in the original image navigation.  McIDAS then has enough information to
map each original pixel into an output pixel.

re: use TOPO/QUAD which has METEOSAT navigation for the IMGREMAPs

>I'll have to think about this...

I just threw this in on the chance that ArcInfo might support idealized
satellite projections.

>perhaps I'll run the program on the data
>and then change the projection... given that the program removes the actual
>radiance values and converts it to yes (1) no (0), maybe it won't be that
>big a deal.


re: workshop starts Monday

>Thanks for being such a big help... other than a couple questions that could
>arise here and there, I understand this part now.  Unfortunately, until the
>program is added to mcidas, I can't test to make sure the new images satisfy
>the programs requirements. 


>Once again, thanks

You are welcome.

**************************************************************************** <
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.