<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: Arial; font-size: 12pt; color: #000000'><P class=MsoNormal style="MARGIN: 0in 0in 0pt"><FONT face="Times New Roman">Mikael,</FONT></P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt"><?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p><FONT face="Times New Roman">&nbsp;</FONT></o:p></P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt"><FONT face="Times New Roman">Thanks for the challenging questions that address the fundamentals of why the Google Sphere is a preposterous misrepresentation of WGS84.<SPAN style="mso-spacerun: yes">&nbsp; </SPAN>Unfortunately, I have only time for a couple points at the moment (at work), but I hope that others with contribute.</FONT></P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt"><o:p><FONT face="Times New Roman">&nbsp;</FONT></o:p></P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt"><FONT face="Times New Roman">First, all local datums (the orientation of an ellipsoid in space and the selection of the ellipsoidal parameters) are developed as best fits to the local geoid (gravity field).<SPAN style="mso-spacerun: yes">&nbsp; </SPAN>Technically, best fit is the least-squares minimization of the deflections of the vertical (the differences between the normal to the ellipsoid and the vertical defined by a plumb bob) over the extent of the datum.<SPAN style="mso-spacerun: yes">&nbsp; </SPAN>So, a datum has a physical constraint, the geoid, which can be measured with simple instruments like a carpenter's level.<SPAN style="mso-spacerun: yes">&nbsp; </SPAN>WGS84 is a best fit to the geoid worldwide.<SPAN style="mso-spacerun: yes">&nbsp; </SPAN>How absurd is it, then, to claim that the Google Sphere is WGS84 when it misses the geoid by 20km at the poles?!?<SPAN style="mso-spacerun: yes">&nbsp; </SPAN>Technically, the deflections squared for the Google Sphere are way larger than for WGS84, as could be demonstrated numerically with EGM96 as a model of geoid, for example.</FONT></P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt"><o:p><FONT face="Times New Roman">&nbsp;</FONT></o:p></P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt"><FONT face="Times New Roman">So, that was a physical argument.<SPAN style="mso-spacerun: yes">&nbsp; </SPAN>My second is conventional.<SPAN style="mso-spacerun: yes">&nbsp; </SPAN>The WGS84 datum is defined (minimum deflections) with the WGS84 ellipsoid.<SPAN style="mso-spacerun: yes">&nbsp; </SPAN>The ED50 datum is defined with the International Ellipsoid.<SPAN style="mso-spacerun: yes">&nbsp; </SPAN>NAD27 (the old <?xml:namespace prefix = st1 ns = "urn:schemas-microsoft-com:office:smarttags" /><st1:country-region w:st="on"><st1:place w:st="on">US</st1:place></st1:country-region> datum) is defined on Clarke 1866.<SPAN style="mso-spacerun: yes">&nbsp; </SPAN>If I could just switch the WGS84 ellipsoid in the WGS84 datum with the Google Sphere (as you suggest), why couldn't I switch the International Ellipsoid in ED50 with Clarke 1866?<SPAN style="mso-spacerun: yes">&nbsp; </SPAN>Or any other switch for that matter?<SPAN style="mso-spacerun: yes">&nbsp; </SPAN>In addition to worse fits mathematically (since the adjustment was done on the defining ellipsoid), we'd open the door to uncertainty and crisis.<SPAN style="mso-spacerun: yes">&nbsp; </SPAN>You are proposing (and Google has introduced) the geodetic equivalent of sub-prime mortgages in the financial market.<SPAN style="mso-spacerun: yes">&nbsp; </SPAN>Don't do it!</FONT></P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt"><o:p><FONT face="Times New Roman">&nbsp;</FONT></o:p></P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt"><FONT face="Times New Roman">Thanks for raising the questions.<SPAN style="mso-spacerun: yes">&nbsp; </SPAN>They need straight answers.</FONT></P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt"><o:p><FONT face="Times New Roman">&nbsp;</FONT></o:p></P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt"><FONT face="Times New Roman">Regards,</FONT></P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt"><FONT face="Times New Roman">Noel Zinn</FONT></P>
<P>
<P>&nbsp;</P>
<P><BR>----- Original Message -----<BR>From: "Mikael Rittri" &lt;Mikael.Rittri@carmenta.com&gt;<BR>To: "PROJ.4 and general Projections Discussions" &lt;proj@lists.maptools.org&gt;<BR>Sent: Monday, December 1, 2008 7:29:22 AM GMT -06:00 US/Canada Central<BR>Subject: RE: [Proj] "Double ellipsoid" case?<BR><BR>Hello Noel, <BR>Sorry if I am stubborn, but I don't see why so many people think that it is obvious that the datum of <BR>Google Mercator cannot be WGS84. &nbsp;For me, it is obvious that the datum _is_ WGS84! &nbsp;<BR>&nbsp;<BR>&nbsp;You wrote:<BR>&nbsp;<BR>&gt; Datums CANNOT be switched under the projection, the whole issue of this "double ellipsoid" thread. &nbsp;<BR>&nbsp;<BR>All right, but I don't see that the datum has been changed during the (Lon,Lat) to (Easting, Northing)<BR>conversion, even if you use Sphere Mercator. <BR>&nbsp;<BR>&gt; The Google Sphere is NOT WGS84. &nbsp;<BR>&nbsp;<BR>Well, I think that depends on your definition of "is". &nbsp;Let me give two motivations: <BR>&nbsp;<BR>A) One can regard Sphere Mercator as a double projection, somewhat similar to Oblique Stereographic, <BR>Swiss cylindrical, Krovak, and a few others. <BR>&nbsp;<BR>&nbsp;&nbsp; &nbsp; Usually, a double projection maps a (Lon_e, Lat_e) on the reference ellipsoid conformally <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;to (Lon_s, Lat_s) on a (Gaussian) sphere, which is then mapped conformally to (E, N) on a plane. &nbsp;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;To get conformality between the ellipsoid and the sphere, Lat_s is slightly different from Lat_e, and Lon_s is <BR>&nbsp;&nbsp; &nbsp; usually slightly different from Lon_e. &nbsp;<BR>&nbsp;<BR>&nbsp;&nbsp; &nbsp; However, for Google Mercator it is quite possible to say that, by definition, Lat_s = Lat_e and Lon_s = Lon_e.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;This defines a mathematical function from the ellipsoid surface to the sphere surface. &nbsp;This function is <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;continuous and one-to-one, so it is a perfectly good map projection, although it is only approximately conformal. &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;As the final step, we use spherical Mercator formulas to map (Lon_s, Lat_s) to the plane. <BR>&nbsp;<BR>&nbsp;&nbsp; &nbsp; If we see Google Mercator in this way, the Google Sphere is indeed not WGS84 (because WGS84 defines an ellipsoid),<BR>&nbsp;&nbsp; &nbsp; but the Sphere is an intermediate step between WGS84 and the plane. &nbsp; Also, any pair of (Lon,Lat) defines a<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;position on both the WGS84 ellipsoid and the Google sphere. &nbsp;You can regards the (Lon,Lat) as a point on the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ellipsoid when you do datum conversion later, or you can regard it as a point on the Google sphere when you are<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;about to use the Mercator formulas.<BR>&nbsp;<BR>B) &nbsp; Alternatively, we could close our eyes hard and say: "there is no sphere in Sphere Mercator". &nbsp;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;EPSG has (reluctantly) defined a map projection method they call <BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"Mercator (1SP) (Spherical)", with coord. op. method code 9841, <BR><BR>&nbsp;&nbsp; &nbsp; which is a different method from the two ellipsoidal projections "Mercator (1SP)" with coord. op. code 9804 &nbsp;<BR>&nbsp;&nbsp; &nbsp; and "Mercator (2SP)" with coord. op. code 9805.<BR>&nbsp;&nbsp; &nbsp; For the spherical formulas, EPSG just refers to Snyder: "Map Projections: A Working Manual". &nbsp;<BR>&nbsp;&nbsp; &nbsp; The trouble is that Snyder's formulas use the parameter R for the spherical radius, and EPSG refuses to <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;say how to get an R out of an ellipsoid (so they cannot allow an ellipsoid datum to be associated with <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;a spherical Mercator). &nbsp;<BR>&nbsp;&nbsp; &nbsp; But they _could_ have said: if the datum is ellipsoidal, R should be taken to be the equatorial radius. &nbsp;<BR>&nbsp;&nbsp; &nbsp; If they had done so, then "Mercator (1SP) (Spherical)" can be regarded as a mathematical function <BR>&nbsp;&nbsp; &nbsp; that maps a point on the reference ellipsoid directly to the plane. &nbsp;If you see the formulas as a black box,<BR>&nbsp;&nbsp; &nbsp; you don't have to think of any sphere: it is enough if the formulas define a function that is continuous and <BR>&nbsp;&nbsp; &nbsp; invertible. <BR>&nbsp;<BR>&nbsp;<BR>&gt; My objection (well, one of my objections) is the implicit expectation that one can do relative <BR>&gt; computations (whatever one does on a map) on a spherical Mercator and "the resulting lat/long <BR>&gt; coordinates are intended to be treated as WGS84 after that" (in Frank's paraphrasing of what &nbsp;<BR>&gt; the Google Maps model implies). &nbsp;That's not true. &nbsp;<BR>&nbsp;<BR>Oh yes. You _can_ compute on the projected plane, unproject, and treat the result as WGS84 after that. &nbsp;<BR>The result may not be exactly what you wanted, but it wouldn't be so with an ellipsoid projection, either. &nbsp;<BR>For example, you wanted to go sqrt(2) * 100 km towards northeast. &nbsp;All right, if you do so by your two <BR>methods, you get two different results. If you instead do it by following a geodetic route on the ellipsoid, <BR>starting towards northeast, and going sqrt(2) * 100 km on the ground, you would get a third result. And if <BR>you did it by following a rhumb line on the ellipsoid in the same way, you would get a fourth result. &nbsp;<BR><BR>Computations in the projected plane simply do not agree exactly with ellipsoid distances and angles. <BR>(Except if you are lucky.) <BR>&nbsp;<BR>Best regards,<BR><BR>--<BR>Mikael Rittri<BR>Carmenta AB<BR>Box 11354<BR>SE-404 28 Göteborg<BR>Visitors: Sankt Eriksgatan 5<BR>SWEDEN<BR>Tel: +46-31-775 57 37<BR>Mob: +46-703-60 34 07<BR>mikael.rittri@carmenta.com<BR>www.carmenta.com <BR><BR>[I am not not quoting all of Noel Zinn's letter here.] <BR><BR><BR>_______________________________________________<BR>Proj mailing list<BR>Proj@lists.maptools.org<BR>http://lists.maptools.org/mailman/listinfo/proj<BR></P></P></div></body></html>