[Proj] Re: Global Gauss-Kruger and libproj4---the final story

[Gerald I. Evenden]

On Wednesday 27 August 2008 5:50:35 pm strebe wrote:
> Surely there is nothing unique to the ellipsoidal transverse Mercator in
> this regard. Consider, for example, a spherical coordinate rotation that
> leaves the equator coincident with the original 180th meridian of any
> cylindric or pseudocylindric projection. In order to draw the equator
> properly, it must be drawn at the locations of both the 180th east and west
> original meridians. There is no end to cases like this.

Yes, you run into them every 10 to 20 years.

> While it is true the location of the cusp varies in the ellipsoidal
> transverse Mercator according to the eccentricity, that is merely a
> parameterization detail. Many projections vary something or another
> according to parameterization, and sometimes what varies is the location or
> extent of an interruption. Once you have an interruption, you have
> one-to-many mapping, and any map line coincident with that interruption
> must be drawn in (at least) two places in order to be correct. All global
> projections are interrupted.

What do you mean by interrupted other than by the longitude boundary.  If you 
are talking about interrupted maps such as Goode's Interrupted Homolosine 
projection, that is generated by 4 initialized libproj4 projection structures 
used by 8 geographic clipping windows for the fully fleshed out version.  
None of the libproj4 entries ever sees a geographic point out of range.  The 
+proj=goode projection used by each of the initialized structures (differing 
only by initializing central meridians) has no "idea" of the complexity of 
the map being drawn and only returns *one* coordinate pair when called.

> Given comments you have made in the past, I gather that the natural
> boundary of the projection is up to the client application (or some other
> library) to compute.

Absolutely.  libproj4 merely handles the projection part.  It doesn't do 
windows.  Those aspects are an entirely different disciplines and involve 
very different procedures.

> This means that any imaging of lines coincident to 
> interruptions must also be up to the client or some other library, since
> interruptions are always part of the natural boundary of the projection.
> Therefore the rationale of one-to-many mapping precluding a global
> ellipsoidal transverse Mercator in iibproj4 is fallacious.

Image or display of the lines has *nothing* to do with the mechanics of 
computing the projection.  In many situations, like grid computing, graphics 
operation are not involved.

> Ways a one-to-many situation may be handled:

If you say so.  It is not the problem of a projection.

> 1) The bare-bones projection package returns all values corresponding to
> the mapped input point.
> This is unsatisfactory when the result is not a 
> finite number of points, such as a pole that is stretched into a line. A

A flat pole is graphically handled by repeated calls to libproj4 by the 
graphic software using varying longitude and fixed latitude at +-90.  
Knowledge of how to deal with various oddities in displaying the projection 
are functions of the calling software.

> sophisticated solution would return an object instance that spits out
> cartesian points according to some parameterized form. In almost all
> instances, it would only spit out one result, but in the case of a typical
> interruption it would spit out two results, and in the case of a
> point-to-line mapping, it would spit out a different cartesian value for
> each value of a supplied parameter.

I have graphic procedures that handle line projection line graphics used in my 
manual and they operate with libproj4 only indicating that a point may be not 
be projectable or the next point has unexpected characteristics.  In all 
cases, libproj4 *only* returns one point per entry with the only abnormal 
return for points not projectable,  Its been working fine for nearly 40 years 
that way.

> I gather this is not an option for libproj4.

I am tired of repeating, libproj4 is *NOT* a graphic routine any more than 
sine or tangent.  In the case of making maps it is merely the process that 
transforms information from one coordinate system to another!

> 2) Don't. Just return a single value and put the onus on the client
> application or some other library. Since libproj4 already does this for the
> projection's natural boundary, client applications already understand that
> they need to know something about the projection in order to do anything
> useful with it. What is true with any projection is true with global
> ellipsoidal transverse Mercator: you need to know the natural boundary of
> the projection in order to draw it.

No other projection has a requirement that the user needs to know an arcane 
formula to manipulate graphical usage to interpret the results.  There is 
currently no means for libproj4 to return such information. 

> Yes, the computation of an ellipsoidal transverse Mercator is an order of
> magnitude (or two) more expensive than series expansions for regions near
> the central meridian. Whether that is useful or practical for the client
> application should be up to the client. Naturally if you (and everyone
> else) is not inclined to program a global ellipsoidal transverse Mercator,
> then it will not happen. I do not encourage abandoning the project for
> reasons that are not reasonable, however.

What is reasonable???  As an academic curiosity---sure. As a practical 
projection?  You have to be kidding!  The last few kilometers of easting are 
so distorted that it is impossible to figure out what one is looking at.  We 
lop off the top and bottom of Mercator, lets have the grace to do the same 
here.

>
> Regards,
> -- daan Strebe
	...
-- 
The whole religious complexion of the modern world is due
to the absence from Jerusalem of a lunatic asylum.
-- Havelock Ellis (1859-1939) British psychologist