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

20001228: 20001207: IMGREMAP: MAG= vs RES= (cont.)

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

Jason,

re: The blow-up/blow-down of an image is always controlled by the MAG=
    keyword.  The use of MAG= in IMGCOPY means the same thing as a MAG= in
    IMGDISP.

>I see.  This makes sense, and it explains why I was getting some of the
>images I was getting when I tinkered with the MAG keyword.

OK, sounds good.

re: To get a flavor for how the coverage stuff (i.e., resolution), display
    one of your images and then draw a circle over it (use CIRCLE) so that
    the center of the circle is in the center of the display.  You can do
    this by finding out a station at/near the center and then specify STA=
    to CIRCLE, or by finding the LAT,LON of the center and then specifying
    the LATLON= keyword in CIRCLE.
  
>Okay... I understand that now.

Excellent.

re: The original GOES-8, -9, -10, and -11 images already have the
    resolution that you are looing to use.  NOTE:  the GOES-7, -6, -5, etc.
    satellites did not do oversampling in the element
    (horizontal/longitudnal) direction, so their Res (km) numbers came out
    looking the same.
 
>Okay... in truth... I got around all this by IMGREMAPing all the GOES 8
>images into a GOES 7 image...

Good, expeditious move.

>as the program I was using required
>(co-location), I had to make sure they were all co-located.  Since I
>had more GOES 7 images, I opted to remap all the images into a GOES 7
>image.  But, it's still good to know about the resolution/magnification
>issue.

Sounds good.

re: You can also use IMGPROBE to list out blocks of values or countour the
    values in a particular region in any unit supported by the image.  
Projection
    in this case does not matter since McIDAS takes this into account.

>Now, this worries me.  How does it take this into account.

IMGPROBE takes the box from the screen and asks the server for data from
the image for each point.

>For
>example, I need to extract the pixel values for a box in Illinois with
>corner lat/long coordinates of:  41 N, 91 W; 41 N, 88 W; 37 N, 88 W; 37
>N, 91 W.  (These are approximate coordinates for the purpose of this
>discussion, but I will have specific lat/long coordinates that will
>define a box).  Moreover, these coordinates are for a box I determined
>in a mercator projection.  How does mcidas take projection into
>account, so that I can figure out what pixels its extracting.

IMGPROBE takes the pixels locations from display space (e.g., the
screen); figures out the center of box specified; figures out how many
lines,elements it takes to get to the upper left and lower right hand
corner of the box; and asks the server to send back values for as many
elements the box covers for all lines that lie between the upper left
and lower right hand corners.  This is want you want, so you should not
be worried.

>By
>looking over the image probe command, I see that I can define a
>lat/long for the ULEFT or the CENTER... which is good... and I can
>determine the SIZ nuber of lines and elements, which I can use to get a
>box worth of pixels, but how does that relate to 'real world'
>coordinates or the coordinates of a mercator projection.

See explanation above.

>Moreover, the
>resolution in the satellite image varies as one goes north and south
>(correct?),

The areal extent of each pixel changes as you move away from the
sub satellite point, yes.

>so if I choose, say 10 line, it really isn't necessarily
>80km (if the resolution is 8km), is it?

No, it isn't, but you can adjust your request to get 80 data within
an 80 km box.

>If every pixel on the image really is 8km,

Again, the areal coverage of each pixel is a function of the distance
it is away from the sub satellite point.  There is no way around this.

>then I suppose I could calculate how many lines/elements
>are in a degree,

You can also use the DIST command to measure the distance between points
in an image.

>and I'll know the coordinates of the box mcidas
>produces when I specify the lat/long and line/element numbers in the
>IMGPROBE command.  I suppose I could define the original box for which
>I want data differently (depending upon what I can do in mcidas), but I
>have to be able to create a coverage in ARC/INFO that covers the same
>geographical location as the pixels I extracted in mcidas (I need to
>'match-up' the pixels with land surface data).

ARC/INFO has to deal with projections in the same way as McIDAS, so the
lessons learned in one package translate to the other.

>So, for however I
>extract the data in mcidas, I need to know the corner coordinates so
>that I can create the coverage in ARC/INFO.Do you have any
>suggestions of how to do this?

I am sort of losing track of your objectives, so please accept the
following general comments.

Getting the corner Lat,Lon positions in McIDAS is easy: use the E
command, and McIDAS will tell you the earth coordinate of the pixel the
cursor is over.

Aside: If you are always dealing with the same location on the surface,
then the lat,lon corner points will be fixed for whatever size box you
want.  As your region of interest moves, you will have to calculate the
change in coverage as a function of Lat,Lon and build that into your
processing.  I have to tell you that the change will not be that large
if your regions of interest remain in the same general area.

On top of all of this, the real location of the pixel from a could top
depends on how deep the cloud is.  This all goes back to worrying about
parallax.  Playing with the McIDAS PLAX command might help some.

>From reading over the IMGPROBE command,
>I think I could get something 'close', but not exact... is there a way
>to do this?

Since the satellites are geosynchronous, the viewing angle for points
is not fixed, so you will never get anything exactly.  McIDAS will do
as good a job as is possible in getting you the values you specify that
you want.

>Thanks for the help.

You are welcome.

Tom