
<html><body name="Mail Message Editor"><div><br></div><span class="Apple-style-span" style="font-family: -webkit-monospace; font-size: 11px; "><span class="Apple-style-span" style="font-family: Helvetica; font-size: 12px; ">On Aug 27, 2008, at 5:32:33 PM, "Gerald I. Evenden" <geraldi.evenden@gmail.com> wrote:</span></span><div><br></div>________<br><div><span class="Apple-style-span" style="font-family: -webkit-monospace; font-size: 11px;"><br></span></div><div><span class="Apple-style-span" style="font-family: -webkit-monospace; font-size: 11px; "><span class="Apple-style-span" style="font-family: Helvetica; font-size: 12px; "><span class="Apple-style-span" style="font-family: -webkit-monospace; font-size: 11px; ">Yes, you run into them every 10 to 20 years.</span></span></span></div><div><span class="Apple-style-span" style="font-family: -webkit-monospace; font-size: 11px;"><br></span></div>________<br><br><div>No, I run into them commonly. Perhaps you run into them every ten or twenty years.<div><div><br>________<br><div><span class="Apple-style-span" style="font-family: -webkit-monospace; font-size: 11px;"><br></span></div><div><span class="Apple-style-span" style="font-family: -webkit-monospace; font-size: 11px; ">No other projection has a requirement that the user needs to know an arcane <br>formula to manipulate graphical usage to interpret the results. There is <br>currently no means for libproj4 to return such information. <br><br></span>________<br><br></div><div>I do not understand that utterance. The problem has nothing to with "graphical usage", whatever that means. It has to do with the results of the projection at a single point. Many world projections do not come with a 90°N/S, 180° E/W natural boundary that the client software can treat as some fixed convention, and all projections have interruptions. An interruption automatically means the projection formulć are not a function, which renders this utterance invalid:<div><br></div><div>________<br><div><br></div><div><div><div><span class="Apple-style-span" style="font-family: -webkit-monospace; font-size: 11px; ">I am tired of repeating, libproj4 is *NOT* a graphic routine any more than <br>sine or tangent. In the case of making maps it is merely the process that <br>transforms information from one coordinate system to another!</span></div><div><br></div><div>________</div><div><br></div><div>Sine and tangent are functions. A projection is not. It is generating formulć that are (usually) a function over the range of the map except at boundaries, where they are multivalued. You have chosen, for your own convenience, to ignore the the possible multiple results of the projecting formulć. That is fine, but it does not make your rant correct; it only makes your decision convenient for you. In any case, if you're tired of repeating yourself, then quit repeating yourself. I suspect everyone else is tired of it, too — particularly because it's a straw man.</div><div><br></div><div>Would you like a list of world projections whose boundaries differ from the boundaries of finite cylindric projections? And if there are many projections with other kinds of boundaries, would you explain again how it is that the ellipsoidal transverse Mercator is somehow unique in that regard?</div><div><br></div><div>I don't care if you don't implement a global ellipsoidal transverse Mercator. If you don't want to implement it, then don't implement it. Surely no one can begrudge that — no one's paying you to, as far as I know. I just don't see the point of rationalizing that decision with sophistry, or why you'd expect your audience to swallow the rationalizations. I suggest just stating that you're not convinced of the value of the work, or that you hate the ellipsoidal transverse Mercator, or that you're tired, and be done with it. Which reminds me: once again, I am tired of these sorts of conversations, and am done with this one.</div><div><br></div><div>Regards,</div><div>-- daan Strebe</div><div><br><div><br></div><div>On Aug 27, 2008, at 5:32:33 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: Helvetica; font-size: 12px; 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; "><div style="width: 100%; "><div id="felix-mail-header-block" style="color: black; background-color: white; border-bottom-width: 1px; border-bottom-style: solid; border-bottom-color: silver; padding-bottom: 1em; margin-bottom: 1em; width: 100%; "><table border="0" cellpadding="1" cellspacing="1" width="100%"><tbody><tr><td width="70px" style="font-family: 'Lucida Grande'; font-size: 8pt; color: gray; text-align: right; vertical-align: top; font-weight: bold; "><span>From:</span></td><td style="font-family: 'Lucida Grande'; font-size: 8pt; color: black; text-align: left; vertical-align: top; padding-left: 5px; "><span title=""Gerald I. Evenden" <geraldi.evenden@gmail.com>">"Gerald I. Evenden" <geraldi.evenden@gmail.com></span></td></tr><tr><td width="70px" style="font-family: 'Lucida Grande'; font-size: 8pt; color: gray; text-align: right; vertical-align: top; font-weight: bold; "><span>Subject:</span></td><td style="font-family: 'Lucida Grande'; font-size: 8pt; color: black; text-align: left; vertical-align: top; padding-left: 5px; "><span style="font-weight: bold; ">Re: Global Gauss-Kruger and libproj4---the final story</span></td></tr><tr><td width="70px" style="font-family: 'Lucida Grande'; font-size: 8pt; color: gray; text-align: right; vertical-align: top; font-weight: bold; "><span>Date:</span></td><td style="font-family: 'Lucida Grande'; font-size: 8pt; color: black; text-align: left; vertical-align: top; padding-left: 5px; "><span>August 27, 2008 5:32:33 PM PDT</span></td></tr><tr><td width="70px" style="font-family: 'Lucida Grande'; font-size: 8pt; color: gray; text-align: right; vertical-align: top; font-weight: bold; "><span>To:</span></td><td style="font-family: 'Lucida Grande'; font-size: 8pt; color: black; text-align: left; vertical-align: top; padding-left: 5px; "><span title="strebe <strebe@aol.com>">strebe <strebe@aol.com></span></td></tr><tr><td width="70px" style="font-family: 'Lucida Grande'; font-size: 8pt; color: gray; text-align: right; vertical-align: top; font-weight: bold; "><span>Cc:</span></td><td style="font-family: 'Lucida Grande'; font-size: 8pt; color: black; text-align: left; vertical-align: top; padding-left: 5px; "><span title="proj@lists.maptools.org">proj@lists.maptools.org</span></td></tr></tbody></table></div><div id="felix-mail-content-block" style="color: black; background-color: white; width: 100%; "><div style="font-family: monospace; color: black; background-color: white; font-size: 8pt; ">On Wednesday 27 August 2008 5:50:35 pm strebe wrote:<br>> Surely there is nothing unique to the ellipsoidal transverse Mercator in<br>> this regard. Consider, for example, a spherical coordinate rotation that<br>> leaves the equator coincident with the original 180th meridian of any<br>> cylindric or pseudocylindric projection. In order to draw the equator<br>> properly, it must be drawn at the locations of both the 180th east and west<br>> original meridians. There is no end to cases like this.<br><br>Yes, you run into them every 10 to 20 years.<br><br>> While it is true the location of the cusp varies in the ellipsoidal<br>> transverse Mercator according to the eccentricity, that is merely a<br>> parameterization detail. Many projections vary something or another<br>> according to parameterization, and sometimes what varies is the location or<br>> extent of an interruption. Once you have an interruption, you have<br>> one-to-many mapping, and any map line coincident with that interruption<br>> must be drawn in (at least) two places in order to be correct. All global<br>> projections are interrupted.<br><br>What do you mean by interrupted other than by the longitude boundary. If you<span class="Apple-converted-space"> </span><br>are talking about interrupted maps such as Goode's Interrupted Homolosine<span class="Apple-converted-space"> </span><br>projection, that is generated by 4 initialized libproj4 projection structures<span class="Apple-converted-space"> </span><br>used by 8 geographic clipping windows for the fully fleshed out version.<span class="Apple-converted-space"> </span><br>None of the libproj4 entries ever sees a geographic point out of range. The<span class="Apple-converted-space"> </span><br>+proj=goode projection used by each of the initialized structures (differing<span class="Apple-converted-space"> </span><br>only by initializing central meridians) has no "idea" of the complexity of<span class="Apple-converted-space"> </span><br>the map being drawn and only returns *one* coordinate pair when called.<br><br>> Given comments you have made in the past, I gather that the natural<br>> boundary of the projection is up to the client application (or some other<br>> library) to compute.<br><br>Absolutely. libproj4 merely handles the projection part. It doesn't do<span class="Apple-converted-space"> </span><br>windows. Those aspects are an entirely different disciplines and involve<span class="Apple-converted-space"> </span><br>very different procedures.<br><br>> This means that any imaging of lines coincident to<span class="Apple-converted-space"> </span><br>> interruptions must also be up to the client or some other library, since<br>> interruptions are always part of the natural boundary of the projection.<br>> Therefore the rationale of one-to-many mapping precluding a global<br>> ellipsoidal transverse Mercator in iibproj4 is fallacious.<br><br>Image or display of the lines has *nothing* to do with the mechanics of<span class="Apple-converted-space"> </span><br>computing the projection. In many situations, like grid computing, graphics<span class="Apple-converted-space"> </span><br>operation are not involved.<br><br>> Ways a one-to-many situation may be handled:<br><br>If you say so. It is not the problem of a projection.<br><br>> 1) The bare-bones projection package returns all values corresponding to<br>> the mapped input point.<br>> This is unsatisfactory when the result is not a<span class="Apple-converted-space"> </span><br>> finite number of points, such as a pole that is stretched into a line. A<br><br>A flat pole is graphically handled by repeated calls to libproj4 by the<span class="Apple-converted-space"> </span><br>graphic software using varying longitude and fixed latitude at +-90.<span class="Apple-converted-space"> </span><br>Knowledge of how to deal with various oddities in displaying the projection<span class="Apple-converted-space"> </span><br>are functions of the calling software.<br><br>> sophisticated solution would return an object instance that spits out<br>> cartesian points according to some parameterized form. In almost all<br>> instances, it would only spit out one result, but in the case of a typical<br>> interruption it would spit out two results, and in the case of a<br>> point-to-line mapping, it would spit out a different cartesian value for<br>> each value of a supplied parameter.<br><br>I have graphic procedures that handle line projection line graphics used in my<span class="Apple-converted-space"> </span><br>manual and they operate with libproj4 only indicating that a point may be not<span class="Apple-converted-space"> </span><br>be projectable or the next point has unexpected characteristics. In all<span class="Apple-converted-space"> </span><br>cases, libproj4 *only* returns one point per entry with the only abnormal<span class="Apple-converted-space"> </span><br>return for points not projectable, Its been working fine for nearly 40 years<span class="Apple-converted-space"> </span><br>that way.<br><br>> I gather this is not an option for libproj4.<br><br>I am tired of repeating, libproj4 is *NOT* a graphic routine any more than<span class="Apple-converted-space"> </span><br>sine or tangent. In the case of making maps it is merely the process that<span class="Apple-converted-space"> </span><br>transforms information from one coordinate system to another!<br><br>> 2) Don't. Just return a single value and put the onus on the client<br>> application or some other library. Since libproj4 already does this for the<br>> projection's natural boundary, client applications already understand that<br>> they need to know something about the projection in order to do anything<br>> useful with it. What is true with any projection is true with global<br>> ellipsoidal transverse Mercator: you need to know the natural boundary of<br>> the projection in order to draw it.<br><br>No other projection has a requirement that the user needs to know an arcane<span class="Apple-converted-space"> </span><br>formula to manipulate graphical usage to interpret the results. There is<span class="Apple-converted-space"> </span><br>currently no means for libproj4 to return such information.<span class="Apple-converted-space"> </span><br><br>> Yes, the computation of an ellipsoidal transverse Mercator is an order of<br>> magnitude (or two) more expensive than series expansions for regions near<br>> the central meridian. Whether that is useful or practical for the client<br>> application should be up to the client. Naturally if you (and everyone<br>> else) is not inclined to program a global ellipsoidal transverse Mercator,<br>> then it will not happen. I do not encourage abandoning the project for<br>> reasons that are not reasonable, however.<br><br>What is reasonable??? As an academic curiosity---sure. As a practical<span class="Apple-converted-space"> </span><br>projection? You have to be kidding! The last few kilometers of easting are<span class="Apple-converted-space"> </span><br>so distorted that it is impossible to figure out what one is looking at. We<span class="Apple-converted-space"> </span><br>lop off the top and bottom of Mercator, lets have the grace to do the same<span class="Apple-converted-space"> </span><br>here.<br><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></div></div></div></span></blockquote><br><div><br></div></div></div></div></div></div></div></div></div></div><div class="aol_ad_footer" id="u5EFA3E26038243E3A1068D2012D948E8"><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>