<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"> </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"> </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"> </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"> </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"> </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"> </SPAN>WGS84 is a best fit to the geoid worldwide.<SPAN style="mso-spacerun: yes"> </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"> </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"> </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"> </SPAN>My second is conventional.<SPAN style="mso-spacerun: yes"> </SPAN>The WGS84 datum is defined (minimum deflections) with the WGS84 ellipsoid.<SPAN style="mso-spacerun: yes"> </SPAN>The ED50 datum is defined with the International Ellipsoid.<SPAN style="mso-spacerun: yes"> </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"> </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"> </SPAN>Or any other switch for that matter?<SPAN style="mso-spacerun: yes"> </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"> </SPAN>You are proposing (and Google has introduced) the geodetic equivalent of sub-prime mortgages in the financial market.<SPAN style="mso-spacerun: yes"> </SPAN>Don't do it!</FONT></P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt"><o:p><FONT face="Times New Roman"> </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"> </SPAN>They need straight answers.</FONT></P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt"><o:p><FONT face="Times New Roman"> </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> </P>
<P><BR>----- Original Message -----<BR>From: "Mikael Rittri" <Mikael.Rittri@carmenta.com><BR>To: "PROJ.4 and general Projections Discussions" <proj@lists.maptools.org><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. For me, it is obvious that the datum _is_ WGS84! <BR> <BR> You wrote:<BR> <BR>> Datums CANNOT be switched under the projection, the whole issue of this "double ellipsoid" thread. <BR> <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> <BR>> The Google Sphere is NOT WGS84. <BR> <BR>Well, I think that depends on your definition of "is". Let me give two motivations: <BR> <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> <BR> Usually, a double projection maps a (Lon_e, Lat_e) on the reference ellipsoid conformally <BR> to (Lon_s, Lat_s) on a (Gaussian) sphere, which is then mapped conformally to (E, N) on a plane. <BR> To get conformality between the ellipsoid and the sphere, Lat_s is slightly different from Lat_e, and Lon_s is <BR> usually slightly different from Lon_e. <BR> <BR> However, for Google Mercator it is quite possible to say that, by definition, Lat_s = Lat_e and Lon_s = Lon_e.<BR> This defines a mathematical function from the ellipsoid surface to the sphere surface. This function is <BR> continuous and one-to-one, so it is a perfectly good map projection, although it is only approximately conformal. As the final step, we use spherical Mercator formulas to map (Lon_s, Lat_s) to the plane. <BR> <BR> If we see Google Mercator in this way, the Google Sphere is indeed not WGS84 (because WGS84 defines an ellipsoid),<BR> but the Sphere is an intermediate step between WGS84 and the plane. Also, any pair of (Lon,Lat) defines a<BR> position on both the WGS84 ellipsoid and the Google sphere. You can regards the (Lon,Lat) as a point on the<BR> ellipsoid when you do datum conversion later, or you can regard it as a point on the Google sphere when you are<BR> about to use the Mercator formulas.<BR> <BR>B) Alternatively, we could close our eyes hard and say: "there is no sphere in Sphere Mercator". <BR> EPSG has (reluctantly) defined a map projection method they call <BR><BR> "Mercator (1SP) (Spherical)", with coord. op. method code 9841, <BR><BR> which is a different method from the two ellipsoidal projections "Mercator (1SP)" with coord. op. code 9804 <BR> and "Mercator (2SP)" with coord. op. code 9805.<BR> For the spherical formulas, EPSG just refers to Snyder: "Map Projections: A Working Manual". <BR> The trouble is that Snyder's formulas use the parameter R for the spherical radius, and EPSG refuses to <BR> say how to get an R out of an ellipsoid (so they cannot allow an ellipsoid datum to be associated with <BR> a spherical Mercator). <BR> But they _could_ have said: if the datum is ellipsoidal, R should be taken to be the equatorial radius. <BR> If they had done so, then "Mercator (1SP) (Spherical)" can be regarded as a mathematical function <BR> that maps a point on the reference ellipsoid directly to the plane. If you see the formulas as a black box,<BR> you don't have to think of any sphere: it is enough if the formulas define a function that is continuous and <BR> invertible. <BR> <BR> <BR>> My objection (well, one of my objections) is the implicit expectation that one can do relative <BR>> computations (whatever one does on a map) on a spherical Mercator and "the resulting lat/long <BR>> coordinates are intended to be treated as WGS84 after that" (in Frank's paraphrasing of what <BR>> the Google Maps model implies). That's not true. <BR> <BR>Oh yes. You _can_ compute on the projected plane, unproject, and treat the result as WGS84 after that. <BR>The result may not be exactly what you wanted, but it wouldn't be so with an ellipsoid projection, either. <BR>For example, you wanted to go sqrt(2) * 100 km towards northeast. 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. <BR><BR>Computations in the projected plane simply do not agree exactly with ellipsoid distances and angles. <BR>(Except if you are lucky.) <BR> <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>