<html><body name="Mail Message Editor">Noel:<div><span class="Apple-style-span" style="background-color: transparent;"><br></span></div><div><span class="Apple-style-span" style="background-color: transparent;"><span class="Apple-style-span" style="font-family: Monaco;">>My physical geodesy argument is that since WGS84 is a best fit to the geoid</span></span></div><div><span class="Apple-style-span" style="background-color: transparent;"><span class="Apple-style-span" style="font-family: Monaco;">>and since the Google Sphere is a terrible fit to the geoid no matter how you</span></span></div><div><span class="Apple-style-span" style="background-color: transparent;"><span class="Apple-style-span" style="font-family: Monaco;">>orientate it, using the Google Sphere obviates reference to the WGS84 datum... </span></span><span class="Apple-style-span" style="background-color: transparent;"><span class="Apple-style-span" style="font-family: Monaco;"><br></span></span></div><div><span class="Apple-style-span" style="background-color: transparent;"><br></span></div><div>To which I reply, the original information from the WGS84 datum is all recoverable from the plane coordinates. Therefore, whether they used the Google Sphere, the WGS84 ellipsoid, or a potato or an icosahedron, so long as the WGS84 coordinates are recoverable, nothing got obviated.</div><div><span class="Apple-style-span" style="background-color: transparent;"><br></span></div><div><span class="Apple-style-span" style="background-color: transparent;"><span class="Apple-style-span" style="font-family: Monaco;">>My geometric geodesy argument would be that geodesic direct and inverse</span></span></div><div><span class="Apple-style-span" style="background-color: transparent;"><span class="Apple-style-span" style="font-family: Monaco;">>computations would get different results on the WGS84 ellipsoid and the GS</span></span></div><div><span class="Apple-style-span" style="background-color: transparent;"><span class="Apple-style-span" style="font-family: Monaco;">>no matter how you map the WGS84 graticule onto the GS graticule. This is an</span></span></div><div><span class="Apple-style-span" style="background-color: transparent;"><span class="Apple-style-span" style="font-family: Monaco;">>indictment of the use of the GS, since WGS84 computations better represent</span></span></div><div><span class="Apple-style-span" style="background-color: transparent;"><span class="Apple-style-span" style="font-family: Monaco;">>physical reality. No one has suggested geodesic computations on the GS in</span></span></div><div><span class="Apple-style-span" style="background-color: transparent;"><span class="Apple-style-span" style="font-family: Monaco;">>this thread, but the implicit association of the GS with WGS84 by Google</span></span></div><div><span class="Apple-style-span" style="background-color: transparent;"><span class="Apple-style-span" style="font-family: Monaco;">>regrettably risks that abuse.</span></span><span class="Apple-style-span" style="background-color: transparent;"><span class="Apple-style-span" style="font-family: Monaco;"><br></span></span></div><div><span class="Apple-style-span" style="background-color: transparent;"><br></span></div><div>Geodesic computations should be performed in spherical coordinates, in which case, again, how those coordinates got projected does not matter so long as the spherical coordinates (on WGS84 ellipsoid) are recoverable. Google does not talk about the "Google Sphere" as far as I can tell; there is no such terminology turned up by a Web search. The specification is clear: geodetic data are given in WGS84 coordinates. I do not see how the projection method encourages anyone to make geodesic computations against the sphere.</div><div><br></div><div>Let me defend that. In order for the Google Map projection to encourage someone to choose the Google Sphere for geodesic calculations, the person would:</div><div><br></div><div>(a) Have to know the projection method; otherwise they would not even be cognizant of the Google Sphere, since it is part of the projection, not the datum from whence coordinates were supplied;</div><div><br></div><div>(b) Realize there is even a Google Sphere to be cognizant of, since it is never explicitly mentioned or promoted;</div><div><br></div><div>(c) Understand there is a difference between ellipsoidal calculations and spherical calculations for distance, and need the precision of the former;</div><div><br></div><div>(d) And still choose the Google Sphere for these geodesic calculations.</div><div><br></div><div>I have to suppose the intersection of (a), (b), (c), and (d) is... nobody.</div><div><span class="Apple-style-span" style="background-color: transparent;"><span class="Apple-style-span" style="font-family: Monaco;"><br></span></span></div><div><span class="Apple-style-span" style="background-color: transparent;"><span class="Apple-style-span" style="font-family: Monaco;">>My appeals to conventional practice are even more compelling in my view, though</span></span></div><div><span class="Apple-style-span" style="background-color: transparent;"><span class="Apple-style-span" style="font-family: Monaco;">>you may disagree.</span></span></div><div><span class="Apple-style-span" style="font-family: Monaco;"><br></span></div><div><span class="Apple-style-span" style="font-family: Monaco;"><span class="Apple-style-span" style="font-family: Helvetica; ">No; I agree. This is your strongest argument. </span><br></span></div><div><span class="Apple-style-span" style="font-family: Monaco;"><br></span></div><div><span class="Apple-style-span" style="background-color: transparent;"><span class="Apple-style-span" style="font-family: Monaco;">>For example, ED50 geodesic direct and inverse computations and ED50 map</span></span></div><div><span class="Apple-style-span" style="background-color: transparent;"><span class="Apple-style-span" style="font-family: Monaco;">>projections are computed _only_ on the International ellipsoid. Why?</span></span></div><div><span class="Apple-style-span" style="background-color: transparent;"><span class="Apple-style-span" style="font-family: Monaco;">>Computation on the ellipsoid of a datum’s least-squares adjustment provides (by</span></span></div><div><span class="Apple-style-span" style="background-color: transparent;"><span class="Apple-style-span" style="font-family: Monaco;">>definition) the best conformation with physical reality and the convention of</span></span></div><div><span class="Apple-style-span" style="background-color: transparent;"><span class="Apple-style-span" style="font-family: Monaco;">>doing so protects us from ignorant mistakes. We all (I believe) follow this</span></span></div><div><span class="Apple-style-span" style="background-color: transparent;"><span class="Apple-style-span" style="font-family: Monaco;">>practice everywhere in the world (except in our use of Google Maps). The risk</span></span></div><div><span class="Apple-style-span" style="background-color: transparent;"><span class="Apple-style-span" style="font-family: Monaco;">>to conventional practice introduced by Google is not progress.<br></span></span></div><div><span class="Apple-style-span" style="background-color: transparent;"><br></span></div><div><div>I agree it is not progress in geodesy. Yet neither do I see it as any practical problem or as backsliding in geodesy. Those who need to perform computations will click a button, and they will receive their computations. I particularly do not agree that the Google Map projection will encourage mistakes. You insist people will interpret the Google Sphere as the datum. I do not believe that. It's just part of the projection calculus. It is a convenient short-cut that some engineers made in order to achieve what they wanted cheaply within acceptable bounds of error. What they wanted was rapid calculations retaining near-conformality so that they could use the same projection mathematics everywhere without introducing visible distortion in large-scale maps. They succeeded. That is the enterprise of engineering.</div><div><br></div><div>And, by the way, they knew what they were doing. They knew they were using not-quite-conformal mathematics and they knew they were doing something unorthodox. Those were acceptable trade-offs to them. The slander heaped upon them in an earlier e-mail was simply slander. No, they are not geodesists, photogrammetrists, or cartographers, but they never represented themselves as any of those, and the problems they were solving were not problems of geodesy or photogrammetry anyway. They were problems of mathematical cartography, and their solution achieved its goals.</div><div><span class="Apple-style-span" style="background-color: transparent;"><span class="Apple-style-span" style="font-family: Monaco;"><br></span></span></div><div><span class="Apple-style-span" style="background-color: transparent;"><span class="Apple-style-span" style="font-family: Monaco;">>So, one thing is certain (and has already been stated in this thread), and that</span></span></div><div><span class="Apple-style-span" style="background-color: transparent;"><span class="Apple-style-span" style="font-family: Monaco;">>is that the Google Maps projection cannot be called the Mercator. </span></span><span class="Apple-style-span" style="background-color: transparent;"><span class="Apple-style-span" style="font-family: Monaco;"><br></span></span></div></div><div><br></div><div>Agreed, certainly with respect to large-scale mapping. For small-scale, well... nobody has coordinate data in spherical datums anyway, so what Google is doing is the de facto standard, even though it is not strictly Mercator.<br></div><div><span class="Apple-style-span" style="background-color: transparent;"><span class="Apple-style-span" style="font-family: Monaco;"><br></span></span></div><div><span class="Apple-style-span" style="background-color: transparent;"><span class="Apple-style-span" style="font-family: Monaco;">>Mikael quantified the maximum angular distortion as 0.2 degrees. At this point</span></span></div><div><span class="Apple-style-span" style="background-color: transparent;"><span class="Apple-style-span" style="font-family: Monaco;">>I’ll have to agree with Cliff that this is retrograde cartography.</span></span><span class="Apple-style-span" style="background-color: transparent;"><span class="Apple-style-span" style="font-family: Monaco;"><br></span></span></div><div><span class="Apple-style-span" style="font-family: Monaco;"><br></span></div><div>At which point I will disagree. There is no use in this context for strict conformality, which is anyway largely a geodetic concern rather than a cartographic concern. Google is not solving geodetic problems and is not causing geodetic problems; therefore it makes no sense to take them to task for violating geodetic practices. There is no "retrograde cartography" going on here, just a rather mundane and obvious variant of a well-known map projection. Cartography has always been about compromises. Did Google pick optimal compromises in their projection choice? It sure seems like it.</div><div><br></div><div>Regards,</div><div>— daan Strebe</div><div><br></div><div><br>On Dec 2, 2008, at 7:31:14 AM, "Noel Zinn" <ndzinn@comcast.net> 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=""Noel Zinn" <ndzinn@comcast.net>">"Noel Zinn" <ndzinn@comcast.net></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; ">[Proj] Re: "Double ellipsoid" case?</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>December 2, 2008 7:31:14 AM PST</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=""'PROJ.4 and general Projections Discussions'" <proj@lists.maptools.org>">"'PROJ.4 and general Projections Discussions'" <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><div class="Section1"><p class="MsoNormal"><font size="3" color="black" face="Comic Sans MS"><span style="font-size: 12pt; font-family: 'Comic Sans MS'; color: black; ">daan, Mikael, Cliff, and others,<o:p></o:p></span></font></p><p class="MsoNormal"><font size="3" color="black" face="Comic Sans MS"><span style="font-size: 12pt; font-family: 'Comic Sans MS'; color: black; "><o:p> </o:p></span></font></p><p class="MsoNormal"><font size="3" color="black" face="Comic Sans MS"><span style="font-size: 12pt; font-family: 'Comic Sans MS'; color: black; ">Thanks for your persistence. Indeed, clarifying our terminology will help. For me the Google Sphere (GS) is simply an ellipsoid with an eccentricity squared of zero and semi-major axis (a) equal to the semi-major axis of the WGS84 ellipsoid. In this case the semi-minor axis (b) equals the semi-major axis. <o:p></o:p></span></font></p><p class="MsoNormal"><font size="3" color="black" face="Comic Sans MS"><span style="font-size: 12pt; font-family: 'Comic Sans MS'; color: black; "><o:p> </o:p></span></font></p><p class="MsoNormal"><font size="3" color="black" face="Comic Sans MS"><span style="font-size: 12pt; font-family: 'Comic Sans MS'; color: black; ">Now, the Google Sphere can have both geodetic and cartographic applications. That distinction is admittedly confusing in this thread. I react viscerally to the introduction of the GS into the WGS84 datum as a geodetic abomination. You and Mikael see the GS as merely an intermediate stage in a total projection method (which is non-conformal and, therefore, not the Mercator projection, and about which you are both defensive). Cliff sees the GS as both bad geodesy and as bad cartography. Frankly, I agree with Cliff. I also accept Richard’s admonition to keep it civil.<o:p></o:p></span></font></p><p class="MsoNormal"><font size="3" color="black" face="Comic Sans MS"><span style="font-size: 12pt; font-family: 'Comic Sans MS'; color: black; "><o:p> </o:p></span></font></p><p class="MsoNormal"><font size="3" color="black" face="Comic Sans MS"><span style="font-size: 12pt; font-family: 'Comic Sans MS'; color: black; ">So, before moving on to the cartography, I’ll briefly recap my geodetic objections. My physical geodesy argument is that since WGS84 is a best fit to the geoid and since the Google Sphere is a terrible fit to the geoid no matter how you orientate it, using the Google Sphere obviates reference to the WGS84 datum (in my opinion). <o:p></o:p></span></font></p><p class="MsoNormal"><font size="3" color="black" face="Comic Sans MS"><span style="font-size: 12pt; font-family: 'Comic Sans MS'; color: black; "><o:p> </o:p></span></font></p><p class="MsoNormal"><font size="3" color="black" face="Comic Sans MS"><span style="font-size: 12pt; font-family: 'Comic Sans MS'; color: black; ">My geometric geodesy argument would be that geodesic direct and inverse computations would get different results on the WGS84 ellipsoid and the GS no matter how you map the WGS84 graticule onto the GS graticule. This is an indictment of the use of the GS, since WGS84 computations better represent physical reality. No one has suggested geodesic computations on the GS in this thread, but the implicit association of the GS with WGS84 by Google regrettably risks that abuse.<o:p></o:p></span></font></p><p class="MsoNormal"><font size="3" color="black" face="Comic Sans MS"><span style="font-size: 12pt; font-family: 'Comic Sans MS'; color: black; "><o:p> </o:p></span></font></p><p class="MsoNormal"><font size="3" color="black" face="Comic Sans MS"><span style="font-size: 12pt; font-family: 'Comic Sans MS'; color: black; ">My appeals to conventional practice are even more compelling in my view, though you may disagree. For example, ED50 geodesic direct and inverse computations and ED50 map projections are computed _only_ on the International ellipsoid. Why? Computation on the ellipsoid of a datum’s least-squares adjustment provides (by definition) the best conformation with physical reality and the convention of doing so protects us from ignorant mistakes. We all (I believe) follow this practice everywhere in the world (except in our use of Google Maps). The risk to conventional practice introduced by Google is not progress.<o:p></o:p></span></font></p><p class="MsoNormal"><font size="3" color="black" face="Comic Sans MS"><span style="font-size: 12pt; font-family: 'Comic Sans MS'; color: black; "><o:p> </o:p></span></font></p><p class="MsoNormal"><font size="3" color="black" face="Comic Sans MS"><span style="font-size: 12pt; font-family: 'Comic Sans MS'; color: black; ">Now, on to the cartography. Having reread Mikael’s postings I appreciate (and accept) his and daan’s perspective that this is a cartographic – and not a geodetic – issue. The WGS84 datum can underlie this (unfortunate) two-stage projection used by Google Maps (Mikael’s alternative A). Regarding Mikael’s alternative B, I’ll have to study the EPSG Mercator methods first before commenting. And regarding daan’s interpretation that only one "ellipsoid" involved on the projection side, and that is the "Google Sphere", I don’t see it yet. I stated previously that the spherical Mercator projection is intuitively conformal. The ellipsoidal Mercator is conformal over a range of eccentricity squared values and there is no reason that that range shouldn’t include zero (the sphere) while maintaining conformality. But first there is the non-conformal mapping from the WGS84 ellipsoid to the Google Sphere before the Mercator equations are applied. So, one thing is certain (and has already been stated in this thread), and that is that the Google Maps projection cannot be called the Mercator. It’s something else. Mikael quantified the maximum angular distortion as 0.2 degrees. At this point I’ll have to agree with Cliff that this is retrograde cartography. Quoting Cliff, “using equivalent spheres in 19th and early 20th century cartography was an attempt to simplify ellipsoidal computations” and quoting Mikael, “the situation is similar to the French truncated Lambert Conformal Conic, which is not exactly conformal, and is a different projection than the true Lambert Conformal Conic”. My question is, Why are we doing this in the 21<sup>st</sup><span class="Apple-converted-space"> </span>century?!? This is retrograde cartography even if (no, especially if) the explanation is computational efficiency (in light of the “clouds” of computers maintained by Google). Google had an opportunity to expose a wide audience to good geodetic and cartographic practice, but instead Google is exposing that audience to malpractice (in my opinion). Yes, this is a judgment. And daan will respond that it works for their purposes. I’m not so sure. Google Maps is being used for lots of creative purposes encouraged by Google. I believe that some user will stumble due to the poor choices made by Google. Perhaps that can be documented in another thread. <o:p></o:p></span></font></p><p class="MsoNormal"><font size="3" color="black" face="Comic Sans MS"><span style="font-size: 12pt; font-family: 'Comic Sans MS'; color: black; "><o:p> </o:p></span></font></p><p class="MsoNormal"><font size="3" color="black" face="Comic Sans MS"><span style="font-size: 12pt; font-family: 'Comic Sans MS'; color: black; ">Regards and thanks for the great discussion,<o:p></o:p></span></font></p><p class="MsoNormal"><font size="3" color="black" face="Comic Sans MS"><span style="font-size: 12pt; font-family: 'Comic Sans MS'; color: black; ">Noel Zinn<o:p></o:p></span></font></p><p class="MsoNormal"><font size="3" color="black" face="Arial"><span style="font-size: 12pt; font-family: Arial; color: black; "><o:p> </o:p></span></font></p><p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size: 12pt; "><o:p> </o:p></span></font></p><p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size: 12pt; "><o:p> </o:p></span></font></p><p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size: 12pt; "><o:p> </o:p></span></font></p><p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size: 12pt; "><o:p> </o:p></span></font></p></div></div><div style="font-family: monospace; color: black; background-color: white; font-size: 8pt; "><pre>_______________________________________________
Proj mailing list
Proj@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj</pre></div></div></div></span></blockquote><br><div><br></div></div><div class="aol_ad_footer" id="u8D0D73A145074866A68419D0224CE021"></div></body></html>