<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">daan,</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">My response to Mikael was from a geodetic perspective.<SPAN style="mso-spacerun: yes"> </SPAN>I hadn't gotten to his cartographic arguments yet.<SPAN style="mso-spacerun: yes"> </SPAN>Maybe tonight or tomorrow.<SPAN style="mso-spacerun: yes"> </SPAN>So, the my main reasoning below has nothing to do with projections.<SPAN style="mso-spacerun: yes"> </SPAN></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">WGS84 is both an ellipsoid (with defined semi-major and semi-minor axes) and a datum (WGS84 ellipsoid geocentrically fixed, spin axis north, and zero longitude through the BIH Zero Meridian).<SPAN style="mso-spacerun: yes"> </SPAN>Also, WGS84 best fits the geoid.<SPAN style="mso-spacerun: yes"> </SPAN>All this is widely documented.<SPAN style="mso-spacerun: yes"> </SPAN>Now, the Google Sphere is a sphere whose radius is the semi-major (Equatorial) axis of the WGS84 ellipsoid.<SPAN style="mso-spacerun: yes"> </SPAN>If we fix the Google Sphere to the Earth as we did the WGS84 ellipsoid (geocentric, spin axis north, and zero longitude through the BIH Zero Meridian), then the north pole on the surface of the Google Sphere will be 20km north of the North Pole on the surface of the Earth.<SPAN style="mso-spacerun: yes"> </SPAN>To get that number subtract the semi-minor (spin) axis from the semi-major axis of the WGS84 ellipsoid.<SPAN style="mso-spacerun: yes"> </SPAN>I conclude, therefore, that the use of the Google Sphere has nothing to do with the WGS84 datum and shouldn't be called that.<SPAN style="mso-spacerun: yes"> </SPAN>It doesn't fit the geoid, which is part of the definition of the WGS84 datum.<SPAN style="mso-spacerun: yes"> </SPAN>End of geodetic argument.</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">There's more to be said cartographically (like any projection that is tangent to the Google Sphere misses the geoid everywhere but the Equator), but perhaps this is enough for now.<SPAN style="mso-spacerun: yes"> </SPAN></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><BR>----- Original Message -----<BR>From: strebe@aol.com<BR>To: proj@lists.maptools.org<BR>Sent: Monday, December 1, 2008 2:28:29 PM GMT -06:00 US/Canada Central<BR>Subject: [Proj] Re: "Double ellipsoid" case?<BR><BR></P></P>
<DIV><FONT face="Arial, Helvetica, sans-serif"><BR>Noel:<BR><BR>I cannot fully understand what it is you have done to deduce that the "Google Sphere" misses "the geoid by 20km at the poles". It's impossible for a projection to miss the geoid. The projection is a development of the datum. You cannot make plane measurements on one projection (Google Sphere on WGS84), treat those results as if you had used a different projection (UTM on WGS84), de-project your results (inverse UTM on WGS84) onto the ellipsoid (WGS84), and then claim that the projection misses the geoid.<BR><BR>How can "Google Sphere" possibly "misrepresent" WGS84? WGS84 is not a projection. It's a datum which Google has assured us is the datum they use when applying their projection technique. The technique is fully specified, it is invertible, and it is convenient for the work they're doing. There is nothing "wrong" with it.<BR><BR>Regards,<BR>— daan Strebe<BR></FONT></DIV>
<DIV><BR></DIV>
<DIV><BR></DIV>-----Original Message-----<BR>From: ndzinn@comcast.net<BR>To: PROJ.4 and general Projections Discussions <proj@lists.maptools.org><BR>Sent: Mon, 1 Dec 2008 6:53 am<BR>Subject: Re: [Proj] "Double ellipsoid" case?<BR><BR>
<DIV id=AOLMsgPart_3_dfc58bdc-7861-4ca1-a12f-75cf3b922c16>
<STYLE>#AOLMsgPart_3_dfc58bdc-7861-4ca1-a12f-75cf3b922c16 p { margin: 0; }</STYLE>
<DIV style="FONT-SIZE: 12pt; COLOR: rgb(0,0,0); FONT-FAMILY: Arial">
<DIV class=MsoNormal style="MARGIN: 0in 0in 0pt"><FONT face="Times New Roman">Mikael,</FONT></DIV>< div class="MsoNormal" style="margin: 0in 0in 0pt;"><FONT face="Times New Roman"> </FONT></DIV>
<DIV 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> </SPAN>Unfortunately, I have only time for a couple points at the moment (at work), but I hope that others with contribute.</FONT></DIV>
<DIV class=MsoNormal style="MARGIN: 0in 0in 0pt"><FONT face="Times New Roman"></FONT> </DIV>
<DIV 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> </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> </SPAN>So, a datum has a physical constraint, the geoid, which can be measured with simple instruments like a carpenter's level.<SPAN> </SPAN>WGS84 is a best fit to the geoid worldwide.<SPAN> </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> </SPAN>Technically, the deflections squared for the Google Sphere are way larger than for WGS84, as coul d be demonstrated numerically with EGM96 as a model of geoid, for example.</FONT></DIV>
<DIV class=MsoNormal style="MARGIN: 0in 0in 0pt"><FONT face="Times New Roman"></FONT> </DIV>
<DIV class=MsoNormal style="MARGIN: 0in 0in 0pt"><FONT face="Times New Roman">So, that was a physical argument.<SPAN> </SPAN>My second is conventional.<SPAN> </SPAN>The WGS84 datum is defined (minimum deflections) with the WGS84 ellipsoid.<SPAN> </SPAN>The ED50 datum is defined with the International Ellipsoid.<SPAN> </SPAN>NAD27 (the old US datum) is defined on Clarke 1866.<SPAN> </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> </SPAN>Or any other switch for that matter?<SPAN> </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> </SPAN>You are proposing (and Google has introduced) the geodetic equivalent of sub-prime mortgages in the financial market.<SPAN> </SPAN>Don't do it!</FONT></DIV>
<DIV class=MsoNormal style="MARGIN: 0in 0in 0pt"><FONT face="Times New Roman"></FONT> </DIV>
<DIV class=MsoNormal style="MARGIN: 0in 0in 0pt"><FONT face="Times New Roman">Thanks for raising the questions.<SPAN> </SPAN>They need straight answers.</FONT></DIV>
<DIV class=MsoNormal style="MARGIN: 0in 0in 0pt"><FONT face="Times New Roman"></FONT> </DIV>
<DIV class=MsoNormal style="MARGIN: 0in 0in 0pt"><FONT face="Times New Roman">Regards,</FONT></DIV>
<DIV class=MsoNormal style="MARGIN: 0in 0in 0pt"><FONT face="Times New Roman">Noel Zinn</FONT></DIV>
<DIV></DIV>
<DIV> </DIV>
<DIV><BR>----- Original Message -----<BR>From: "Mikael Rittri" <<A href="mailto:Mikael.Rittri@carmenta.com" target=_blank>Mikael.Rittri@carmenta.com</A>><BR>To: "PROJ.4 and general Projections Discussions" <<A href="mailto:proj@lists.maptools.org" target=_blank>proj@lists.maptools.org</A>><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> &nb sp; 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 p oint 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><A href="mailto:mikael.rittri@carmenta.com" target=_blank>mikael.rittri@carmenta.com</A><BR><A href="http://www.carmenta.com/" target=_blank>www.carmenta.com</A> <BR><BR>[I am not not quoting all of Noel Zinn's letter here.] <BR><BR><BR>_______________________________________________<BR>Proj mailing list<BR><A href="mailto:Proj@lists.maptools.org" target=_blank>Proj@lists.maptools.org</A><BR><A href="http://lists.maptools.org/mailman/listinfo/proj" target=_blank>http://lists.maptools.org/mailman/listinfo/proj</A><BR></DIV>
<DIV></DIV></DIV>
<DIV></DIV><!-- end of AOLMsgPart_3_dfc58bdc-7861-4ca1-a12f-75cf3b922c16 -->
<DIV id=AOLMsgPart_4_dfc58bdc-7861-4ca1-a12f-75cf3b922c16 style="FONT-SIZE: 12px; MARGIN: 0px; COLOR: rgb(0,0,0); FONT-FAMILY: Tahoma,Verdana,Arial,Sans-Serif; BACKGROUND-COLOR: rgb(255,255,255)"><PRE style="FONT-SIZE: 9pt"><TT>_______________________________________________<BR>
Proj mailing list<BR>
<A href="mailto:Proj@lists.maptools.org" target=_blank>Proj@lists.maptools.org</A><BR>
<A href="http://lists.maptools.org/mailman/listinfo/proj" target=_blank>http://lists.maptools.org/mailman/listinfo/proj</A><BR>
</TT></PRE></DIV><!-- end of AOLMsgPart_4_dfc58bdc-7861-4ca1-a12f-75cf3b922c16 -->
<DIV class=aol_ad_footer id=MAILCIAMA018-5baf493448ed372><BR><FONT style="FONT: 10pt ARIAL, SAN-SERIF; COLOR: black">
<HR style="MARGIN-TOP: 10px">
</HR>Tis the season to save your money! <A href="http://toolbar.aol.com/holiday/download.html?ncid=emlweusdown00000008" target=_blank>Get the new AOL Holiday Toolbar</A> for money saving offers and gift ideas. </DIV><BR>_______________________________________________ Proj mailing list Proj@lists.maptools.org http://lists.maptools.org/mailman/listinfo/proj</FONT></div></body></html>