<html><body name="Mail Message Editor"><div>Noel,</div><div><br></div><div>I believe this excerpt illuminates why we have different perspectives. You wrote:</div><div><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="color: rgb(0, 0, 0); "><div id="felix-mail-content-block" style="color: black; background-color: white; width: 100%; "><div><o:smarttagtype namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="City"><o:smarttagtype namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="place"><o:smarttagtype namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="PersonName"><div class="Section1"><p class="MsoNormal"><font size="2" color="navy" face="Arial"><span style="font-size: 10pt; font-family: Arial; color: navy; ">However, I take issue with your statement that Google “</span></font>have simply defined a map projection”. A<font size="2" color="navy" face="Arial"><span style="font-size: 10pt; font-family: Arial; color: navy; ">ny defined map projection should have defined distortions, even non-conformal projections. I demonstrated how a user can extract geodesic distances from grid coordinates and point scale factors using Simpson’s Approximation. That’s the way most surveyors work (I believe), not using (recovered) geographicals and geodesic computations, though we may agree that’s the best route. What user knows to take the WGS84 ratio of rho and nu (the radii of curvature in the meridian and prime vertical) with the Equatorial radius and apply those to the spherical Mercator point scales in order to find the real distortions in GMP? If Google haven’t defined that they haven’t defined a map projection. If they have, I’d appreciate a reference. </span></font></p><p class="MsoNormal"><font size="2" color="navy" face="Arial"><span style="font-size: 10pt; font-family: Arial; color: navy; ">These issues are buried in the noise for small scale maps, as you have mentioned. But the “novelty” of GMP is my concern, and that is that these undocumented distortions are present in large scale maps that might be used for real work in the field. </span></font></p></div></o:smarttagtype></o:smarttagtype></o:smarttagtype></div></div></span></blockquote></div><div><br></div><div>Google Maps is for finding routes for automobile trips on roads. The application and its user interface are constructed for that purpose, and their Terms of Use reflect that. Indeed, with respect to the optional photographic imagery, commercial use of any kind is prohibited. While they recognize and provide for other uses, you might as well be taking an AAA map to task for showing a road's line caricature as wider than its to-scale width when there never was any implication that it was supposed to be to scale.</div><div><br></div><div>I never thought of the products of Google Maps as surveying tools or as maps providing rigorous information with known, bounded error. People who use their maps that way are asking for trouble. The data, as spelled out in the Terms of Use, are culled and amalgamated from a variety of sources, the accuracy of which cannot be assumed. I don't have much sympathy for people who expect professional results from free, online services. They should go to you for professional services and pay you well for them.</div><div><br></div><div>I do not agree that a map projection must define point scale errors in order to be called a map projection. Of the two hundred odd map projections I have written program code for using original sources, perhaps a tithe come with developing formulæ for point scale and for angular distortion. Only a handful come with developing formulæ for the ellipsoid — which is unnecessary anyway, given auxiliary latitudes, unless some specific property is intended to be preserved beyond that preserved by the auxiliary latitude. The fact that Google does not publish distortion formulæ does not mean it is unknowable. As these things go, the derivation is simple. Even if an analytic derivation were not available, numeric techniques suffice.<br></div><div><br></div><div>I'm fairly sure I understand your points. I'm just extremely skeptical of disparaging Google for not adhering to practices defined by a profession outside their purview on complaints arising from uses they specifically disclaim. The benefits Google Maps brings to the public drastically outweigh the importance of this highly technical debate. Perhaps it is your opinion that the service could have been so much the better if they had only stuck with a conformal ellipsoidal development. In my opinion, that improvement, if it is one at all, would be outweighed by the electrical costs of the computations or even by the probability of introducing programming errors: conformal inverse ellipsoidal projections are not trivial to code for.</div><div><br></div><div>I need to bow out of this conversation; I really don't think there's much more to say and I'm sure a lot of our audience has already gone home. Still, I'm uncomfortable letting a one-sided (and rather negative) interpretation prevail, particularly if it has practical implications. </div><div><br></div><div>Thanks & regards,</div><div>— daan Strebe</div><div><br></div><br>On Dec 7, 2008, at 8:10:59 PM, "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 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; ">RE: [Proj] RE: "Double Ellipsoid" error, reproduction</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 7, 2008 8:10:59 PM 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><o:smarttagtype namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="City"><o:smarttagtype namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="place"><o:smarttagtype namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="PersonName"><div class="Section1"><p class="MsoNormal"><font size="2" color="navy" face="Arial"><span style="font-size: 10pt; font-family: Arial; color: navy; ">daan,<o:p></o:p></span></font></p><p class="MsoNormal"><font size="2" color="navy" face="Arial"><span style="font-size: 10pt; font-family: Arial; color: navy; "><o:p> </o:p></span></font></p><p class="MsoNormal"><font size="2" color="navy" face="Arial"><span style="font-size: 10pt; font-family: Arial; color: navy; ">Your objection constitutes a valid perspective, as we agreed. I have a different perspective.<o:p></o:p></span></font></p><p class="MsoNormal"><font size="2" color="navy" face="Arial"><span style="font-size: 10pt; font-family: Arial; color: navy; "><o:p> </o:p></span></font></p><p class="MsoNormal"><font size="2" color="navy" face="Arial"><span style="font-size: 10pt; font-family: Arial; color: navy; ">The fact that “</span></font>the original geographic coordinates are recoverable through a known, rigorous process” d<font size="2" color="navy" face="Arial"><span style="font-size: 10pt; font-family: Arial; color: navy; ">oes not support your case. The geographic coordinates of the original datum are always recoverable with a reverse transformation from the geographicals of the transformed datum (well, except for the 10-parameter Molodensky-Badekas, which is almost invertible with negligible discrepancies). That’s why consistent use of the same transformation is more important than switching to a “more accurate” transformation as new empirical evidence comes in. <o:p></o:p></span></font></p><p class="MsoNormal"><font size="2" color="navy" face="Arial"><span style="font-size: 10pt; font-family: Arial; color: navy; "><o:p> </o:p></span></font></p><p class="MsoNormal"><font size="2" color="navy" face="Arial"><span style="font-size: 10pt; font-family: Arial; color: navy; ">But you make a strong point in that “</span></font>There is nothing empirical; no information is lost; and there is no error”, a<font size="2" color="navy" face="Arial"><span style="font-size: 10pt; font-family: Arial; color: navy; ">t least in the mathematical sense. On the other hand, my experience is replete with naïve users switching ellipsoids with zero geocentric offsets and getting into trouble. This is risky behavior that should be discouraged in my perspective (working in an industry that is already risky). But your statement is technically correct. Furthermore, this ellipsoid switch in the first stage of Google Maps Projection (GMP) is not a transformation of the 7-parameter of the similarity type (Helmert, Bursa Wolf), which is conformal, at least in ECEF (XYZ) space. We have already established that this ellipsoid switch is the cause of the non-conformality in the GMP. <o:p></o:p></span></font></p><p class="MsoNormal"><font size="2" color="navy" face="Arial"><span style="font-size: 10pt; font-family: Arial; color: navy; "><o:p> </o:p></span></font></p><p class="MsoNormal"><font size="2" color="navy" face="Arial"><span style="font-size: 10pt; font-family: Arial; color: navy; ">However, I take issue with your statement that Google “</span></font>have simply defined a map projection”. A<font size="2" color="navy" face="Arial"><span style="font-size: 10pt; font-family: Arial; color: navy; ">ny defined map projection should have defined distortions, even non-conformal projections. I demonstrated how a user can extract geodesic distances from grid coordinates and point scale factors using Simpson’s Approximation. That’s the way most surveyors work (I believe), not using (recovered) geographicals and geodesic computations, though we may agree that’s the best route. What user knows to take the WGS84 ratio of rho and nu (the radii of curvature in the meridian and prime vertical) with the Equatorial radius and apply those to the spherical Mercator point scales in order to find the real distortions in GMP? If Google haven’t defined that they haven’t defined a map projection. If they have, I’d appreciate a reference.<o:p></o:p></span></font></p><p class="MsoNormal"><font size="2" color="navy" face="Arial"><span style="font-size: 10pt; font-family: Arial; color: navy; "><o:p> </o:p></span></font></p><p class="MsoNormal"><font size="2" color="navy" face="Arial"><span style="font-size: 10pt; font-family: Arial; color: navy; ">These issues are buried in the noise for small scale maps, as you have mentioned. But the “novelty” of GMP is my concern, and that is that these undocumented distortions are present in large scale maps that might be used for real work in the field. <o:p></o:p></span></font></p><p class="MsoNormal"><font size="2" color="navy" face="Arial"><span style="font-size: 10pt; font-family: Arial; color: navy; "><o:p> </o:p></span></font></p><p class="MsoNormal"><font size="2" color="navy" face="Arial"><span style="font-size: 10pt; font-family: Arial; color: navy; ">We have different perspectives. On one hand, GMP is just another projection in the universe of possible projections (which is true). On the other hand, GMP is risky (I’d rather say deviant) cartographic behavior (which is also true). <o:p></o:p></span></font></p><p class="MsoNormal"><font size="2" color="navy" face="Arial"><span style="font-size: 10pt; font-family: Arial; color: navy; "><o:p> </o:p></span></font></p><p class="MsoNormal"><font size="2" color="navy" face="Arial"><span style="font-size: 10pt; font-family: Arial; color: navy; ">Thanks for catching my lapse,<o:p></o:p></span></font></p><p class="MsoNormal"><font size="2" color="navy" face="Arial"><span style="font-size: 10pt; font-family: Arial; color: navy; ">Noel<o:p></o:p></span></font></p><p class="MsoNormal"><font size="2" color="navy" face="Arial"><span style="font-size: 10pt; font-family: Arial; color: navy; "><o:p> </o:p></span></font></p></div></o:smarttagtype></o:smarttagtype></o:smarttagtype></div></div></span></blockquote><br><div><br></div><div class="aol_ad_footer" id="u283CD5605CC14B07B8E2342CA05105C2"></div></body></html>