20020213: reading/writing McIDAS area files for use in GEMPAK (cont.)

>From: David Ovens <address@hidden>
>Organization: University of Washington
>Keywords: 200202121913.g1CJDNx21764 McIDAS AREA

David,

>If you look in http://www.atmos.washington.edu/~ovens/testimages/
>you will find 3 GIF images and 3 commented *lwu_pokes files that show
>how the bogus McIDAS AREA file used in the corresponding plot was
>generated.  Turns out that once I found the right words to POKE, this
>was possible and both McIDAS-X and GEMPAK can handle it (for the most
>part).

Super!  I had never tried this since manipuation of METEOSAT imagery
was so easy.  Congradulations!!

For the tracking system, here is one of the set of POKEs you did to
an image from the Unidata-Wisconsin datastream to rotate the image
so that Seattle was the subsatellite point:

LWU COPY AREA0121 AREA7799     # GOES-WEST IR from Wisconsin, LDM
LWU POKE AREA7799 2535 5       # upper-left image line coord.
                               #  This rounded out the top of image.

LWU POKE AREA7799 5700 6       # upper-left image element coord.
                               #  This shifts image to the right.

LWU POKE AREA7799 2000 8       # number of lines in the image
                               #  This can pull us in and out from Earth.

LWU POKE AREA7799 2500 9       # number of data points per line
                               #  This expanded us so that edge of
                               #  Earth circle is visible.
            
LWU POKE AREA7799 -23561945 69 #  / 10,000,000 = ref. long. radians, 1350W
LWU POKE AREA7799 6000000 71   #  / 10,000,000 = ref. lat. radians,  ~340N

Just for interest, I did all of these POKEs to a copy of one of
the GOES-West VIS images from the Unidata-Wisconsin datastream (LDM
feed type MCIDAS):

IMGCOPY RTIMAGES/GW-VIS MYDATA/IMAGES.1234 SIZE=ALL
LWU POKE AREA1234 2535 5
LWU POKE AREA1234 5700 6
LWU POKE AREA1234 2000 8
LWU POKE AREA1234 2500 9
LWU POKE AREA1234 -23561945 69
LWU POKE AREA1234 6000000 71

I tried displaying and manipulating the resultant image with McIDAS ADDE:

IMGDISP MYDATA/IMAGES.1234                 <- worked

Trying an IMGDISP with a blowdown of -3 (MAG=-3) resulted in an IMGDISP
invocation that would not end:

IMGDISP MYDATA/IMAGES.1234 MAG=-3

After killing it, however, I was able to draw a MAP in
the frame including LAT,LON lines.  Next I tried a IMGREMAP of
topography data into the "POKEd" image copy, and IMGREMAP would not
exit either:

IMGREMAP TOPO/GLOB MYDATA/IMAGES.1234 SMOOTH=YES

Interestingly, however, using old non-ADDE McIDAS routines, I was
able to REMAP a global topography image into the copy and then display
and map it:

REMAP 9000 1234 SMOOTH=YES

REMAP - TRANFORMATIONS COMPLETE..BEGIN DATA MOVE
--REMAP DONE

IMGDISP MYDATA/IMAGES.1234 MAG=-4 LINELE=1000 1200 PLA=C

Beginning Image Data transfer, bytes= 480816
IMGDISP: loaded frame  1
IMGDISP: done
 
MAP H 1 LALO -2 INT=10 10
MAP: Completed frame 1
 
FRMSAVE 1 rotategoes.gif TYPE=FRAME FORM=GIF 

The results of this exercise can be seen in:

http://www.unidata.ucar.edu/staff/tom/gifs/rotategoes.gif

Cute!

>One thing I am wondering if you could still help on is the
>apparent bug in the mapping.  Look for Greenland in the various plots
>and you'll see that only avn3_2002021300_000.gif has its complete
>outline.  Similar disappearances of the lat/lon lines also occur near
>the pole.

This is a GEMPAK question.

>I realize that what I've done to generate the AREA file is pretty
>klugey, but I still wonder if I can get trick GEMPAK into creating
>avn1_2002021300_000.gif with a full map and lat/lon lines.  If I add
>more bogus data to the file to correspond to the POKEd words (5, 6, 8,
>and 9), would this make the maps and lat/lon labels around the pole
>reappear? 

I will leave this one for Chiz.

Cheers,

Tom