<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 type="text/css">#AOLMsgPart_3_dfc58bdc-7861-4ca1-a12f-75cf3b922c16 p { margin: 0; }</style>
<div style="font-family: Arial; font-size: 12pt; color: rgb(0, 0, 0);">
<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 style=""> </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 style=""> </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=""> </span>So, a datum has a physical constraint, the geoid, which can be measured with simple instruments like a carpenter's level.<span style=""> </span>WGS84 is a best fit to the geoid worldwide.<span style=""> </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=""> </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 style=""> </span>My second is conventional.<span style=""> </span>The WGS84 datum is defined (minimum deflections) with the WGS84 ellipsoid.<span style=""> </span>The ED50 datum is defined with the International Ellipsoid.<span style=""> </span>NAD27 (the old US datum) is defined on Clarke 1866.<span style=""> </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=""> </span>Or any other switch for that matter?<span style=""> </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=""> </span>You are proposing (and Google has introduced) the geodetic equivalent of sub-prime mortgages in the financial market.<span style=""> </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 style=""> </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">Mikael.Rittri@carmenta.com</a>><br>
To: "PROJ.4 and general Projections Discussions" <<a href="mailto:proj@lists.maptools.org">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">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">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>
<!-- end of AOLMsgPart_3_dfc58bdc-7861-4ca1-a12f-75cf3b922c16 -->
<div id="AOLMsgPart_4_dfc58bdc-7861-4ca1-a12f-75cf3b922c16" style="margin: 0px; font-family: Tahoma,Verdana,Arial,Sans-Serif; font-size: 12px; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
<pre style="font-size: 9pt;"><tt>_______________________________________________<br>
Proj mailing list<br>
<a href="mailto:Proj@lists.maptools.org">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 id='MAILCIAMA018-5baf493448ed372' class='aol_ad_footer'><BR/><FONT style="color: black; font: normal 10pt ARIAL, SAN-SERIF;"><HR style="MARGIN-TOP: 10px"></HR> Tis the season to save your money! <a href="http://toolbar.aol.com/holiday/download.html?ncid=emlweusdown00000008">Get the new AOL Holiday Toolbar</a> for money saving offers and gift ideas. </div>