>From: David Fitzgerald <address@hidden> >Organization: Millersville University of Pennsylvania >Keywords: 200005251529.e4PFTAT21216 McIDAS-X MAP navigation registration Dave, >Strange thing going on when loading images on McIDAS. Regardless of >the image I load, whether it be NIDS, or any of the satellite or >composite images, the map that is being overlaid on the image is >incorrect. It is always the same map, and looks like a GOES-E >satellite map, however even when I load a GOES-E image, the map is not >aligned properly with the image. I tried deleteing .mcidasrc and .mctmp >bu that didn't seem to help. > >What should I look for to find the problem? You don't say how you go about displaying the image before running into the problem. There are two distinct possibilities: o you are displaying images and using a VIRTual graphic as the overlay for the map o you are loading the images and then running MAP to put the map on The first instance can be an indication of running from the Fkey or MCGUI menus. In this case, it is likely that a VIRTual graphic file that is being used is not one that has write permission for the user doing the display. This would be the case if the VIRT file existed in a directory in the user's MCPATH but was owned by a different user so that the read/write permissions would only allow reads. The way to check for VIRT files like this is to use DMAP from the user's McIDAS-X session: DMAP VIRT Look through the list and verify that each VIRT file is writable by the user trying to put maps on top of images. The second situation is an indication that one of the transitory files that McIDAS uses on a per-session basis exists in a MCPATH directory. If this is the case, that file must be deleted before things will return to normal. To check this situation, you should use the DMAP command from the user's McIDAS-X session to find out where that file is found: DMAP *.001 DMAP F*.* If the list that comes back has files with the '.001' suffix in any directory other than one under .mctmp, then those files must be deleted. Here is the output from these commands on a properly running system: DMAP *.001 PERM SIZE LAST CHANGED FILENAME DIRECTORY ---- --------- ------------ ------------ --------- -rw- 58752 May 25 07:03 FRAMENH.001 /home/mcidas/.mctmp/42240 -rw- 45056 May 25 06:52 TERMCHAR.001 /home/mcidas/.mctmp/42240 103808 bytes in 2 files DMAP F*.* PERM SIZE LAST CHANGED FILENAME DIRECTORY ---- --------- ------------ ------------- --------- -rw- 2181 Jun 07 1999 FO14DEC.CFG /home/mcidas/workdata -rw- 772 Jun 04 1999 FONTNAME.DAT /home/mcidas/data -rw- 31665 Jun 04 1999 FOUS14.DAT /home/mcidas/data -rw- 1644 Jul 11 1999 FRAME.PROG /home/mcidas/data -rw- 1981 Jul 11 1999 FRAMECUR.PROG /home/mcidas/data -rw- 58752 May 25 07:03 FRAMENH.001 /home/mcidas/.mctmp/42240 -rw- 3072 May 25 07:03 Frame1.0 /home/mcidas/.mctmp/42240 -rw- 3072 May 25 06:52 Frame10.0 /home/mcidas/.mctmp/42240 -rw- 3072 May 25 06:52 Frame11.0 /home/mcidas/.mctmp/42240 -rw- 3072 May 25 06:52 Frame12.0 /home/mcidas/.mctmp/42240 -rw- 3072 May 25 06:52 Frame13.0 /home/mcidas/.mctmp/42240 -rw- 3072 May 25 06:52 Frame14.0 /home/mcidas/.mctmp/42240 -rw- 3072 May 25 06:52 Frame15.0 /home/mcidas/.mctmp/42240 -rw- 3072 May 25 06:52 Frame16.0 /home/mcidas/.mctmp/42240 -rw- 3072 May 25 06:52 Frame17.0 /home/mcidas/.mctmp/42240 -rw- 3072 May 25 06:52 Frame2.0 /home/mcidas/.mctmp/42240 -rw- 3072 May 25 06:52 Frame3.0 /home/mcidas/.mctmp/42240 -rw- 3072 May 25 06:52 Frame4.0 /home/mcidas/.mctmp/42240 -rw- 3072 May 25 06:52 Frame5.0 /home/mcidas/.mctmp/42240 -rw- 3072 May 25 06:52 Frame6.0 /home/mcidas/.mctmp/42240 -rw- 3072 May 25 06:52 Frame7.0 /home/mcidas/.mctmp/42240 -rw- 3072 May 25 06:52 Frame8.0 /home/mcidas/.mctmp/42240 -rw- 3072 May 25 06:52 Frame9.0 /home/mcidas/.mctmp/42240 149219 bytes in 23 files The files from the 'DMAP F*.*' list that are not a problem are the ones that have a non-numerical suffix. The 'FrameN.M' files are the frame directory for each frame in your session. These files contain the navigation for the frame, so I am betting that if the second option is the problem, then one or more FrameN.M files will be found by DMAP in a directory in the user's MCPATHB _other_ than the directory under .mctmp. >Thanks! > >Dave > >++++++++++++++++++++++++++ >David Fitzgerald >System Administrator Phone: (717) 871-2394 >Millersville University Fax: (717) 871-4725 >Millersville, PA 17551 E-mail: address@hidden >
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.