<html><body name="Mail Message Editor"><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Ways a one-to-many situation may be handled:</div><div><br></div><div>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.</div><div><br></div><div>I gather this is not an option for libproj4.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Regards,</div><div>-- daan Strebe</div><div><br></div><br>On Aug 27, 2008, at 1:40:19 PM, "Gerald I. Evenden" <geraldi.evenden@gmail.com> wrote:<br><blockquote style="padding-left: 5px; margin-left: 5px; border-left-width: 2px; border-left-style: solid; border-left-color: blue; color: blue; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: -webkit-monospace; font-size: 11px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; ">On Wednesday 27 August 2008 1:40:43 pm strebe wrote:<br>> Not knowing anything about libproj4, I am surprised by this note. All<br>> projections of the complete globe are "multivariate". What does libproj4 do<br>> for other projections? Why would it not do something similar for<br>> ellipsoidal transverse Mercator?<br><br>Of course there is what might be called longitude "wrap around" of<span class="Apple-converted-space"> </span><br>unrestrained longitude. libproj4 clips longitude at pi to prevent such<span class="Apple-converted-space"> </span><br>problems (can be overridden). Granted there is an ambiguity at lon=pi(180)<span class="Apple-converted-space"> </span><br>but that is the problem that is well understood and to be resolved by the<span class="Apple-converted-space"> </span><br>calling applications. But libproj4 and any predecessor gives only *one*<span class="Apple-converted-space"> </span><br>answer at lambda=pi.<span class="Apple-converted-space"> </span><br><br>In the case of the split of the equator by TM, the longitude where the split<span class="Apple-converted-space"> </span><br>occurs is determined by the eccentricity of the ellipsoid and thus there is<span class="Apple-converted-space"> </span><br>no "standard" longitude of occurrence. Regardless of this detail it creates<span class="Apple-converted-space"> </span><br>a problem totally unique to TM and would require specialized modification of<span class="Apple-converted-space"> </span><br>application programs merely to handle this single projection. Given the<span class="Apple-converted-space"> </span><br>*very* questionable application of TM in this region there is no practical<span class="Apple-converted-space"> </span><br>excuse to pursue this problem. Also, unless I missed something in Lee's and<span class="Apple-converted-space"> </span><br>Thompson's math, the mechanism for computing TM by their math would create<span class="Apple-converted-space"> </span><br>execution times orders of magnitude slower than any of the current<span class="Apple-converted-space"> </span><br>approximations.<br><br>There are certainly legit debate over extended TM (beyond UTM zones) but I do<span class="Apple-converted-space"> </span><br>not see any reason to continue with global TM.<br><br>> Regards,<br>> -- daan Strebe<br>...<br>--<span class="Apple-converted-space"> </span><br>The whole religious complexion of the modern world is due<br>to the absence from Jerusalem of a lunatic asylum.<br>-- Havelock Ellis (1859-1939) British psychologist<br></span></blockquote><br><div><br></div><div class="aol_ad_footer" id="uF3D396D0765748DF8CC8AC1EA123BEFA"><FONT style="color: black; font: normal 10pt ARIAL, SAN-SERIF;"><HR style="MARGIN-TOP: 10px">Check out <A title="http://video.aol.com/show/ap/101923?ncid=aolvdp00050000000184" href="http://video.aol.com/show/ap/101923?ncid=aolvdp00050000000184" target="_blank">AOL Video</A> to see what's making news today!</FONT></div></body></html>