Possible Problem with GCTP Map Projections

QUESTION: Has anyone run into the problem that subsequent calls to MAP_PROJ_INIT using a GCTP projection interfere with previously defined map projections in IDL 6.3? Here is an example of what I mean:

   IDL> south_proj=MAP_PROJ_INIT('Polar Stereographic'  ,/GCTP ,$
        semimajor_axis=6378273.0,semiminor_axis=6356889.4,$
        center_lon=0,center_lat=-70.0,false_easting=0,false_northing=0)

   IDL> print,map_proj_forward([0,0],[-90.0,-89.0],map_structure=south_proj)
          0.0000000       0.0000000
          0.0000000       108332.24

   IDL> north_proj=MAP_PROJ_INIT('Polar Stereographic'  ,/GCTP ,$
         semimajor_axis=6378273.0,semiminor_axis=6356889.4,$
         center_lon=0,center_lat=70.0,false_easting=0,false_northing=0)

   IDL> print,map_proj_forward([0,0],[-90.0,-89.0],map_structure=south_proj)
          0.0000000  -2.0002841e+23
          0.0000000  -1.4035070e+09

I haven't yet seen this occur if the second projection is a non-GCTP projection. However the non-GCTP projections are not normally useful since they can't be set up like a normal projections with false easting and false northing and they are mostly spherical not ellipsoidal.

ANSWER: This appears to be a bug to me. But the original poster supplied some additional information for a possible work-around.

I looked into MAP_PROJ_INIT and found these two internal routines: MAP_PROJ_GCTP_FORINIT and MAP_PROJ_GCTP_REVINIT. If you call them with the proper parameters for each projection before any call to MAP_PROJ_FORWARD or MAP_PROJ_INVERSE the calculations are correct. I would guess there is an internal structure somewhere that can only hold parameters for one GCTP projection at once. I've submitted a bug report to ITTVIS and await an answer.

The word from ITTVIS technical support is that information is being cached internally when a GCTP projection is initialized. If a second, MAP_PROJ_INIT is called, that cached information is written over and wipes out the information from the initial MAP_PROJ_INIT. The bug is being tracked (C.R.I.D #38654), but it will not be fixed for the forthcoming IDL 6.4 release.

The suggested work-around for this bug is to be sure to call MAP_PROJ_INIT immediately before calling MAP_PROJ_FORWARD or MAP_PROJ_INVERSE, so that the transformations are always taking place with the proper map structure.

Note: We have finally managed to get to the bottom of this problem. You can find the details in this article.

Google
 
Web Coyote's Guide to IDL Programming