[OSRS-PROJ] Confusing case of the Stereographic

[Alexander Weidauer]

Thank you

Gerald for that fast help.

Bye Alexander Weidauer

Gerald I. Evenden schrieb:
> 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.
> 
> -------------------------------------------------------------------
> 


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