[Proj] Re: "Double ellipsoid" case?

Mon Dec 1 20:54:00 EST 2008

 [With apologies to the moderator for the long thread history I did not chop off on my first quarantined attempt.]

Noel:

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, "Google Sphere" seems to refer to either of the projection (or some part of it) or to an
"ellipsoid".

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.

If, on the other hand, I interpret your usage of "Google Sphere" to mean the projection scheme, then I would interpret "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.

If, on yet someone else's hand, I interpret your usage of "Google Sphere" to mean the ellipsoid of the projection, then I would interpret "Google Sphere is not WGS84" to mean that=2
0the projection is not developed from the WGS84 ellipsoid. That is true. 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.

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?

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.

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".

Regards,

— daan Strebe

daan,

My response to Mikael was from a geodetic perspective.  I hadn't gotten to his cartographic arguments yet.  Maybe tonight or tomorrow.  So, the my main reasoning below has nothing to do with projections.  

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).  Also, WGS84 best fits the geoid.  All this is widely documented.  Now, the20Google Sphere is a sphere whose radius is the semi-major (Equatorial) axis of the WGS84 ellipsoid.  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.  To get that number subtract the semi-minor (spin) axis from the semi-major axis of the WGS84 el
lipsoid.  I conclude, therefore, that the use of the Google Sphere has nothing to do with the WGS84 datum and shouldn't be called that.  It doesn't fit the geoid, which is part of the definition of the WGS84 datum.  End of geodetic argument.

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.  

Regards,

Noel Zi
nn

-----Original Message-----

From: ndzinn at comcast.net

To: PROJ.4 and general Projections Discussions <proj at lists.maptools.org>

Sent: Mon, 1 Dec 2008 1:46 pm

Subject: Re: [Proj] Re: "Double ellipsoid" case?

daan,

My response to Mikael was from a geodetic perspective.  I hadn't gotten to his cartographic arguments yet.  Maybe tonight or tomorrow.  So, the my main reasoning below has nothing to do with projections.  

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).  Also, WGS84 best fits the
 geoid.  All this is widely documented.  Now, the Google Sphere is a sphere whose radius is the semi-major (Equatorial) 
axis of the WGS84 ellipsoid.  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.  To get that number subtract the semi-minor (spin) axis from the semi-major axis of the WGS84 ellipsoid.  I conclude, therefore, that the use of the Google Sphere has nothing to do with the WGS84 datum and shouldn't be called that.  It doesn't fit the geoid, which is part of the definition of the WGS84 datum.  End of geodetic argument.

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.  

Regards,

Noel Zinn

----- Original Message -----

From: strebe at aol.com

To: proj at lists.maptools.org

Sent: Monday, December 1, 2008 2:28:29 PM GMT -06:00 US/Canada Central

Subject: [Proj] Re: "Double ellipsoid" case?

Noel:

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=2
0(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.

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.

Regards,

— daan Strebe

-----Original Message-----

From: ndzinn at comcast.net

To: PROJ.4 and genera
l Projections Discussions <proj at lists.maptools.org>

Sent: Mon, 1 Dec 2008 6:53 am

Subject: Re: [Proj] "Double ellipsoid" case?

Mikael,

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

Thanks
for the challenging questions that address the fundamentals of why the
Google Sphere is a preposterous misrepresentation of WGS84.  Unfortunately, I have only time for a couple points at the moment (at work), but I hope that others with contribute.

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).  Technically, best fit is
the least-squares minimization of the defle
ctions 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.  So, a datum has a physical constraint, the geoid, which can be measured with simple instruments like a carpenter's level.  WGS84 is a best fit to the geoid worldwide.  How absurd is it, then, to claim that the Google Sphere is WGS84 when it misses the geoid by 20km at the poles?!?  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.

So, that was a physical argument.  My second is conventional.  The WGS84 datum is defined (minimum deflections) with the WGS84 ellipsoid.  The ED50 datum is defined with the International Ellipsoid.  NAD27 (the old US datum) is defined on Clarke 1866.  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?  Or any other switch for that matter?  In
addition to worse fits mathematically (since the adjustment was done on
the defining ellipsoid), we'd open the door to uncertainty and crisis.  You are proposing (and Google has introduced) the geodetic equivalent of sub-prime mort
gages in the financial market.  Don't do it!

Thanks for raising the questions.  They need straight a
nswers.

Regards,

Noel Zinn

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maptools.org/pipermail/proj/attachments/20081201/4749bb12/attachment.html