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