This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
>From: Unidata User Support <address@hidden> >Organization: Unidata Program Center/UCAR >Keywords: 200403150130.i2F1U8rV014748 McIDAS IMGREMAP Hi, A Unidata McIDAS user reported a problem using IMGREMAP with the MERGE=YES option as follows: >I am making a global composite (G-10, G-12, MET, IND, GMS) of the southern >hemisphere in RECT proj: > ># Create basemap from Topo files >imgremap.k TOPO/GLOB MYDATA/IMAGES.1 PRO=RECT SIZE=ALL RES=5 >imgcopy.k MYDATA/IMAGES.1 MYDATA/IMAGES.2 LINELE=1500 0 SIZE=2100 8000 >imgcopy.k MYDATA/IMAGES.2 MYDATA/IMAGES.3 LINELE=0 1685 SIZE=2100 1805 ... ># Remap Imagery onto basemaps >imgremap.k GWR/GWFDSK04I4 MYDATA/IMAGES.2 DAY=${datej} TIME=02 04 >imgremap.k GER/GEFDSK04I4 MYDATA/IMAGES.3 DAY=${datej} TIME=02 04 ... ># Remap imagery into first basemap >imgremap.k MYDATA/IMAGES.3 MYDATA/IMAGES.2 MERGE=YES SSIZE=ALL ... ># Give it correct date >imgcha.k MYDATA/IMAGES.2 CTYPE=BRIT SS=70 BAND=4 TIME=03:00:00 DAY=${datej} >MEMO > >IMGREMAP bombs when I try to do the first merge..G-12 onto the G10 basemap. >MYDATA/IMAGES.3 merged into MYDATA/IMAGES.2. The error message that >can be seen when DEV=CCC is specified on the IMGREMAP command line is: > >IMGREMAP* Opened connection to write destination >IMGREMAP* Pre fail check code >IMGREMAP* Merge Data >IMGREMAP* invalid parm - can't get pointer for handle=3 >IMGREMAP* (handle.c): parameter ERROR at line 293 >IMGREMAP: Failed to remap the image >IMGREMAP* ERROR --- domap= -1 >IMGREMAP failed, RC=1 > >The script is running >fine right now with the 7.8 version of IMGREMAP. I have verified that the IMGREMAP MERGE=YES invocation fails on Sun Solaris SPARC 5.9, and my user verified that the command fails on RedHat 9 Linux and Sun Solaris x86. I searched the McIDAS Inquiry tracking system and found that INQ 12313: IMGREMAP gives "invalid parm - can't get pointer for handle=2" error when the destination image is a MODIS area. One conjecture in the inquiry entry was that the problem was related to the LAT,LON navigation of the MODIS data: "*** This is no longer being fixed in #12132. I'm re-opening this inquiry. Dave says that he thinks part of the bug is in the LALO navigation routine, which will probably be very difficult to fix....it can't handle the 2 lat/lon navs that IMGREMAP is trying to setup. ***" The data that my user is merging is remapped GOES East and West data, so the problem is not limited to LAT,LON navigations like those in MODIS. A second comment in the MUG inquiry was: "See inquiry 12132. The bug in this inquiry is being addressed there." I reviewed INQ 12132 and noted that imgremap.f had updates to v 1.86; the version in McIDAS v2003x is v 1.80. I grabbed the most recent imgremap.f source and tried using it to see if my user's problem was fixed by the various changes -- it is not. Since INQ 12132 does not seem to quite hit the mark for the problems we are seeing, I am asking that this problem report be added to INQ 12313. By the way, I have been looking through the code and see how the program is failing: there is a call to mcafree( destination ) so that the destination handle is freed, even though it is attempted to be used in a call to domap further along in the code. Thanks in advance for any insight you can give us on this remapping problem. Cheers, Tom