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

[strebe]

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.

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.

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. 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.

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

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 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 gather this is not an option for libproj4.

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.

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.

Regards,
-- daan Strebe


On Aug 27, 2008, at 1:40:19 PM, "Gerald I. Evenden" <geraldi.evenden at gmail.com> wrote:
On Wednesday 27 August 2008 1:40:43 pm strebe wrote:
> Not knowing anything about libproj4, I am surprised by this note. All
> projections of the complete globe are "multivariate". What does libproj4 do
> for other projections? Why would it not do something similar for
> ellipsoidal transverse Mercator?

Of course there is what might be called longitude "wrap around" of 
unrestrained longitude. libproj4 clips longitude at pi to prevent such 
problems (can be overridden). Granted there is an ambiguity at lon=pi(180) 
but that is the problem that is well understood and to be resolved by the 
calling applications. But libproj4 and any predecessor gives only *one* 
answer at lambda=pi. 

In the case of the split of the equator by TM, the longitude where the split 
occurs is determined by the eccentricity of the ellipsoid and thus there is 
no "standard" longitude of occurrence. Regardless of this detail it creates 
a problem totally unique to TM and would require specialized modification of 
application programs merely to handle this single projection. Given the 
*very* questionable application of TM in this region there is no practical 
excuse to pursue this problem. Also, unless I missed something in Lee's and 
Thompson's math, the mechanism for computing TM by their math would create 
execution times orders of magnitude slower than any of the current 
approximations.

There are certainly legit debate over extended TM (beyond UTM zones) but I do 
not see any reason to continue with global TM.

> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20080827/88056245/attachment.html>