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.
Copyright © 2007 David W. Fanning
Last Updated 1 January 2007