[OSRS-PROJ] Confusing case of the Stereographic

[Gerald I. Evenden]

Mr. Weidauer was kind enough to send a copy of his earlier email
to OSRS-PROJ directly to me and I responded directly back to him
with additional notes on the projection problem.  My earlier
comments to OSRS-PROJ about the elliptical/equitorial Stereographic
projection error are correct.  However, I will include my
more detailed response to Weidauer here:

---------------------------------------------------------------------

Thanks for the bug report.  More notes below.

On Thu, 2003-07-03 at 12:32, Alexander Weidauer wrote:
> Hi Gerald Evenden,
> 
> Here the lost message again
> 
> I testing with GIS datas from ESRI default sets around
> and use the delivered world30 grid from a shapefile
> in certain projections for a demo program.
> 
> I know that the usage of some coordinates are stupid setted
> in response to certain projections but he bevahior of proj is
> really strange if I use the stereogrphic one .
> 
> I use fllowing sets of data:
> [~ !] proj +proj=stere +ellps=WGS84
This is equitorial mode where lat_0=0 and lon_0=0 (default values)
Apode is at 180,0 and is focus of projection.
> -180 90
> 0.00    25512548.00
above should read
0.00    12756274.00
> -180 -90
> 0.00    -25512548.00
same as above but /2.0
> -180 -180
> *       *
> -180 180
> *       *
> -180 360
> *       *
> -180   0     <---- but here the program crashes
It shouldn't but should read * * but since other the basics were
screwed up ... .
> The program crashes with division by zero only if I use zero but wit
360 
> is all ok. This happens also also in the DLL version. Any suggetions ?
> 
> Regards Alexander Weidauer

If you want to make a personal fix, go into file PJ_stere.c and look
for a line after the first "switch" statement in routine "e_forward"
then go to "case EQUIT."  The next line starts out as:

        A = 2. * P->akm1 / ...

change it to read:

        A = P->akm1 / ...

that is, remove the "2. *" part.

Sorry about this.  It seems that Snyder did not include a computational
check for the equitorial case and I followed suit.

Another good check is to compute the case for:

1' 0
1855.32 -0.00
0 1'
0.00    1842.90

where the 1' should come close to a nautical mile.

There was no correction for the inverse which would have also
been a check (feeding the forward values into the inverse).
Also -V is a good check as the projection should be shown to be
conformal.  But in this case the error version was
still conformal as the output was merely scaled (by 2) and
-V would have been no help.

Thanks again.

-------------------------------------------------------------------

-- 
Gerald I. Evenden <gerald.evenden at verizon.net>

----------------------------------------
PROJ.4 Discussion List
See http://www.remotesensing.org/proj for subscription, unsubscription
and other information.