[Proj] Oblique Stereographic

[Gerald Evenden]

I am enclosing my reponse to a recent email that may interest this 
group:

	From: 	  gerald.evenden at verizon.net
	Subject: 	Re: Oblique Stereographic Alternative (sterea.pdf)
	Date: 	May 3, 2004 10:27:15 AM EDT
	To: 	  r_j_schulz at yahoo.ca

Thank-you for your comments about the Oblique Stereographic.

First, as far as naming the projection this is a problem for the global
situation.  The simple designation of "Oblique Stereographic" in the 
U.S.
usually designates the Snyder/GCTP form because it was the form
used by the USGS.  Obviously, this is a parochial view and not 
necessarily
shared by the global community.

These two forms also cannot be named because of the "double" nature
of their projection process because *both* oblique projections are
double projections.  Snyder's version uses a simplified conversion to
the conformal sphere while sterea uses a more generalized form.

The comment about the k factor is correct and both 7 and 8 should read
R_c k.  Using k as a variable name is unfortunate as it usually refers
to the scale factor.  I will probably rewrite 7 and 8 as R_c f k_0 where
f is the current k and k_0 is the user selected scale factor at the
central point.  Equations 10 and 11 need correcting.

As for the arcsin, I will change it to a call to aasin; a function that 
accounts
for the near unity cases.  This hassle in common in libproj4 
projections.

As for the clarity of my code, thank-you for your complement.  But I 
think
EPSG should be chastised a bit for the lack of organization and clarity
of their mathematical presentations.

Again, thank-you for your comments.

I hope you will not mind if I forward your comments and my reply to the
remotesensing email list as they distribute a version of PROJ.4 and
follow activities with libproj4.

On May 3, 2004, at 12:50 AM, Rueben Schulz wrote:

> To Gerald Evenden,
>
> Hello. If you remember, I bugged you about the stereographic 
> alternative
> projection (PJ_sterea.c) in libproj4 last summer. At that time I was
> implementing the oblique stereographic projection (EPSG code 9809, same
> as the stereographic alternative) in the geotools2 coordinate
> transformation module. Since then I have learned a bit more about this
> projection and discovered some possible typos in your summary notes. I
> am passing this information on in the hopes that it may be useful.
>
> In December, I bugged the EPSG about the name of this projection and
> what to call the USGS form. They recommend that the name remain 
> "Oblique
> Stereographic" and that the USGS version be called something else. The
> USGS version will be called the "Stereographic" in geotools2. The EPSG
> does not have any plans to include the USGS form in their database 
> since
> they do not know of any coordinate reference systems that use it.
>
> A representative from esri helpfully pointed out that ersi (and others)
> call the oblique stereographic the double stereographic. This allowed 
> me
> to track down some documents from UNB with the equations for the double
> stereographic:
>
> Krakiwsky, E.J., D.B. Thomson, and R.R. Steeves. 1977. A Manual For
> Geodetic Coordinate Transformations in the Maritimes. Geodesy and
> Geomatics Engineering, UNB. Technical Report No. 48.
>
> Thomson, D.B., M.P. Mepham and R.R. Steeves. 1977. The Stereographic
> Double Projection. Surveying Engineering, University of New Brunswick.
> Technical Report No. 46.
>
> The first report give a summary of the equations while the second gives
> the derivation. The forward equations match the ones you give, but UNB
> used a different method in the inverse to iterate for the latitude.
>
> While comparing the equations, I found some possible typos in your
> "Supplementary PROJ.4 Notes - Oblique Stereographic Alternative"
> document (sterea.pdf). Equations 7 and 8 are missing the k (equation 
> 9).
> Also, equations 8, 9 and 12 use phic0 which is given as X (chi) in
> equation 5.
>
> Lastly, when I was testing the geotools implementation (java, based on
> your code) I found that the latitude for the inverse of points on the
> earth's poles was undefined. This turned out to be a rounding error 
> that
> caused the contents of the arcsin() in equation 12 to be slightly
> outside of +- 1.0. I added a check to solve this (like the sinchk in 
> the
> orthographic inverse (PJ_ortho.c)).
>
> Thank you again for your work. The documentation for your equations is
> much clearer than that given by the epsg.
>
> Rueben Schulz
>
>
>
_____________________________________
Jerry and the low riders: Daisy Mae and Joshua
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 4956 bytes
Desc: not available
Url : http://lists.maptools.org/pipermail/proj/attachments/20040503/0475e154/attachment.bin