<div> <font face="Arial, Helvetica, sans-serif">[With apologies to the moderator for the long thread history I did not chop off on my first quarantined attempt.]<br>
<br>


Noel:<br>


<br>


Thank you for the explanation; I think understand much better now what
you mean, in which case I still conclude that Mikael's arguments are
all spot-on. I'm still a little confused about part of what you're
saying and why you're saying it. Depending up on who means what when
they're saying it in this discussion, </font><font face="Arial, Helvetica, sans-serif">"Google Sphere" seems to refer to either of the projection (or some part of it) or to an
"ellipsoid".</font><br>


<font face="Arial, Helvetica, sans-serif"><br>


If an ellipsoid, then to say the "Google Sphere is not WGS84" is to
state the obvious. It is hard to imagine that is what you mean, except
that you have proceeded to demonstrate how far off the geoid the Google
Sphere is. Certainly no one is saying that the Google Sphere is
equivalent to the WGS84 ellipsoid.<br>


<br>


If, on the other hand, I interpret your usage of "Google Sphere" to mean the projection scheme, then I would interpret </font><font face="Arial, Helvetica, sans-serif">"Google
Sphere is not WGS84" to mean that the projection system is not based on
the WGS84 datum. That is false. Google requires that the datum for
geodetic coordinates supplied to Google Maps be WGS84. If you try to
use coordinates defined by some other datum, then you will not have a
georeferenced map.<br  >


<br>


If, on yet someone else's hand, I interpret your usage of "Google Sphere" to mean the ellipsoid of the projection, </font><font face="Arial, Helvet  ica, sans-serif">then I would interpret </font><font face="Arial, Helvetica, sans-serif">"Google Sphere is not WGS84" to mean that the projection is not developed from the WGS84 ellipsoid. That is true. </font><font face="Arial, Helvetica, sans-serif">The
purpose of the Google Sphere in their projection scheme is to anchor
the nominal scale of the map. That's all. Its relation to the WGS84
ellipsoid is that it takes its radius to be the WGS84 semimajor axis.
There is no particular reason NOT to have chosen their radius that way.
It certainly seems like nothing to get excited about.<br>


<br>


I can't find anything reasonable in all the invective directed toward
the Google Maps projection in this thread. It's a projection. It's
well-defined. It works for their purposes. That's what projections are
for: to work for the purpose. No, it's not conformal. No, it's not some
other projection that some people expect or might want to see. But
neither is it unreasonable, preposterous, or misleading. Indeed,
small-scale maps on the Mercator projection have always been
constructed this way, since small-scale projections are spherically
based even though survey data based on a sphere does not exist. The
only (debatably) controversial aspect of Google's deployment is not to
have used an ellipsoidal development despite dealing with large-scale
data. The practical consequence is 
that they do not have a conformal
projection; hence local distances measured from a point are not quite
uniform in all directions, and neither are azimuths quite equally
spaced radially from that point. So?<br>


<br>


Let us keep the terminology distinct. If we talk about the Google Maps
projection, then let us call it that. The Google Sphere (to use the term coined on this thread, as far as I can tell) is the
ellipsoid for that projection. WGS84 is the datum for the geodetic
coordinates for that projection.<br>
<br>
Having said all this, and returning to the thread's subject, we're not dealing with a double ellipsoid case in any real sense. There is only one "ellipsoid" involved on the projection side, and that is the "Google Sphere".<br>


<br>


</font><font face="Arial, Helvetica, sans-serif">Regards,<br>


— daan Strebe<br>


<br>


</font></div>


<blockquote style="border-left: 2px solid blue; padding-left: 3px;">


<div class="MsoNormal" style="margin: 0in 0in 0pt;"><font face="Times New Roman">daan,</font></div>






<div class="MsoNormal" style="margin: 0in 0in 0pt;"><font face="Times New Roman">&nbsp;</font></div>






<div class="MsoNormal" style="margin: 0in 0in 0pt;"><font face="Times New Roman">My response to Mikael was from a geodetic perspective.<span style="">&nbsp; </span>I hadn't gotten to his cartographic arguments yet.<span style="">&nbsp; </span>Maybe tonight or tomorrow.<span style="">&nbsp; </span>So, the my main reasoning below has nothing to do with projections.<span style="">&nb
sp; </span></font></div>






<div class="MsoNormal" style="margin: 0in 0in 0pt;"><font face="Times New Roman">&nbsp;</font></div>






<div 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="">&nbsp; </span>Also, WGS84 best fits the geoid.<span style="">&nbsp; </span>All this is widely documented.<span style="">&nbsp; </span>Now, the20Google Sphere is a sphere whose radius is the semi-major (Equatorial) axis of the WGS84 ellipsoid.<span style="">&nbsp; </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="">&nbsp; </span>To get that number subtract the semi-minor (spin) axis from the semi-major axis of the WGS84 ellipsoid.<span style="">&nbsp; </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="">&nbsp; </span>It doesn't fit the geoid, which is part of the definition of the WGS84 datum.<span style="">&nbsp; </span>End of geodetic argument.</font></div>






<div class="MsoNormal" style="margin: 0in 0in 0pt;"><font face="Times New Roman">&nbsp;</font></div>






<div 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="">&nbsp; </span></font></div>






<div class="MsoNormal" style="margin: 0in 0in 0pt;"><font face="Times New Roman">&nbsp;</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 Zi
nn</font></div>






<div>
</div>


</blockquote>


<div> <br>


</div>





<div> <br>


</div>





<div> <br>


</div>


-----Original Message-----<br>


From: <a href="mailto:ndzinn@comcast.net">ndzinn@comcast.net</a><br>


To: PROJ.4 and general Projections Discussions &lt;<a href="mailto:proj@lists.maptools.org">proj@lists.maptools.org</a>&gt;<br>


Sent: Mon, 1 Dec 2008 1:46 pm<br>


Subject: Re: [Proj] Re: "Double ellipsoid" case?<br>


<br>












<div id="AOLMsgPart_3_0367a584-7d53-4222-b53a-62844fb665c2"><style type="text/css">#AOLMsgPart_2_a832b175-0c1a-4b32-a4cb-690a16303f36 #AOLMsgPart_3_0367a584-7d53-4222-b53a-62844fb665c2 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">daan,</font></div>






<div class="MsoNormal" style="margin: 0in 0in 0pt;"><font face="Times New Roman">&nbsp;</font></  div>






<div class="MsoNormal" style="margin: 0in 0in 0pt;"><font face="Times New Roman">My response to Mikael was from a geodetic perspective.<span style="">&nbsp; </span>I hadn't gotten to his cartographic arguments yet.<span style="">&nbsp; </span>Maybe tonight or tomorrow.<span style="">&nbsp; </span>So, the my main reasoning below has nothing to do with projections.<span style="">&nbsp; </span></font></div>






<div class="MsoNormal" style="margin: 0in 0in 0pt;"><font face="Times New Roman">&nbsp;</font></div>






<div 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="">&nbsp; </span>Also, WGS84 best fits the
 geoid.<span style="">&nbsp; </span>All this is widely documented.<span style="">&nbsp; </span>Now, the Google Sphere is a sphere whose radius is the semi-major (Equatorial) axis of the WGS84 ellipsoid.<span style="">&nbsp; </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="">&nbsp; </span>To get that number subtract the semi-minor (spin) axis from the semi-major axis of the WGS84 ellipsoid.<span style="">&nbsp; </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="">&nbsp; </span>It doesn't fit the geoid, which is part of the definition of the WGS84 datum.<span style="">&nbsp; </span>End of geodetic argument.</font></div>






<div class="MsoNormal" style="margin: 0in 0in 0pt;"><font face="Times New Roman">&nbsp;</font></div>






<div 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="">&nbsp; </span></font></div>






<div class="MsoNormal" style="margin: 0in 0in 0pt;"><font face="Times New Roman">&nbsp;</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><br>


----- Original Message -----<br>


From: <a href="mailto:strebe@aol.com">strebe@aol.com</a><br>


To: <a href="mailto:proj@lists.maptools.org">proj@lists.maptools.org</a><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>


</div>








<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: <a href="mailto:ndzinn@comcast.net">ndzinn@comcast.net</a><br>


To: PROJ.4 and genera
l Projections Discussions &lt;<a href="mailto:proj@lists.maptools.org">proj@lists.maptools.org</a>&gt;<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_2_a832b175-0c1a-4b32-a4cb-690a16303f36 #AOLMsgPart_3_0367a584-7d53-4222-b53a-62844fb665c2 #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=3  D"margin: 0in 0in 0pt;"><font face="Times New Roman">Mikael,</font></div>


&lt; div class="MsoNormal" style="margin: 0in 0in 0pt;"&gt;<font face="Times New Roman">&nbsp;</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>&nbsp; </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;">&nbsp;</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>&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 e
xtent of the datum.<span>&nbsp; </span>So, a datum has a physical constraint, the geoid, which can be measured with simple instruments like a carpenter's level.<span>&nbsp; </span>WGS84 is a best fit to the geoid worldwide.<span>&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>&nbsp; </span>Technically,
the deflections squared for the Google Sphere are way larger than f
or
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;">&nbsp;</div>






<div class="MsoNormal" style="margin: 0in 0in 0pt;"><font face="Times New Roman">So, that was a physical argument.<span>&nbsp; </span>My second is conventional.<span>&nbsp; </span>The WGS84 datum is defined (minimum deflections) with the WGS84 ellipsoid.<span>&nbsp; </span>The ED50 datum is defined with the International Ellipsoid.<span>&nbsp; </span>NAD27 (the old US datum) is defined on Clarke 1866.<span>&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>&nbsp; </span>Or any other switch for that matter?<span>&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>&nbsp; </span>You are proposing (and Google has introduced) the geodetic equivalent of sub-prime mort
gages in the financial market.<span>&nbsp; </span>Don't do it!</font></div>






<div class="MsoNormal" style="margin: 0in 0in 0pt;">&nbsp;</div>






<div class="MsoNormal" style="margin: 0in 0in 0pt;"><font face="Times New Roman">Thanks for raising the questions.<span>&nbsp; </span>They need straight answers.</font></div>






<div class="MsoNormal" style="margin: 0in 0in 0pt;">&nbsp;</div>






<div class="MsoNormal" style="margin: 0in 0in 0pt;"><f  ont 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>&nbsp;</div>

</div>

</div>

</div>

<div id='MAILCIAMA044-5c6b49349538230' 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>