[Proj] Re: "Double ellipsoid" case?

Mon Dec 1 13:46:09 PST 2008

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 (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 general 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 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.   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 mortgages in the financial market.   Don't do it! 

Thanks for raising the questions.   They need straight answers. 

Regards, 
Noel Zinn 

----- Original Message ----- 
From: "Mikael Rittri" < Mikael.Rittri at carmenta.com > 
To: "PROJ.4 and general Projections Discussions" < proj at lists.maptools.org > 
Sent: Monday, December 1, 2008 7:29:22 AM GMT -06:00 US/Canada Central 
Subject: RE: [Proj] "Double ellipsoid" case? 

Hello Noel, 
Sorry if I am stubborn, but I don't see why so many people think that it is obvious that the datum of 
Google Mercator cannot be WGS84.  For me, it is obvious that the datum _is_ WGS84!   

 You wrote: 

> Datums CANNOT be switched under the projection, the whole issue of this "double ellipsoid" thread.   

All right, but I don't see that the datum has been changed during the (Lon,Lat) to (Easting, Northing) 
conversion, even if you use Sphere Mercator. 

> The Google Sphere is NOT WGS84.   

Well, I think that depends on your definition of "is".  Let me give two motivations: 

A) One can regard Sphere Mercator as a double projection, somewhat similar to Oblique Stereographic, 
Swiss cylindrical, Krovak, and a few others . 

     Usually, a double projection maps a (Lon_e, Lat_e) on the reference ellipsoid conformally 
        to (Lon_s, Lat_s) on a (Gaussian) sphere, which is then mapped conformally to (E, N) on a plane.   
        To get conformality between the ellipsoid and the sphere, Lat_s is slightly different from Lat_e, and Lon_s is 
     usually slightly different from Lon_e.   

     However, for Google Mercator it is quite possible to say that, by definition, Lat_s = Lat_e and Lon_s = Lon_e. 
        This defines a mathematical function from the ellipsoid surface to the sphere surface.  This function is 
        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. 

     If we see Google Mercator in this way, the Google Sphere is indeed not WGS84 (because WGS84 defines an ellipsoid), 
     but the Sphere is an intermediate step between WGS84 and the plane.   Also, any pair of (Lon,Lat) defines a 
        position on both the WGS84 ellipsoid and the Google sphere.  You can regards the (Lon,Lat) as a point on the 
      &nb sp; ellipsoid when you do datum conversion later, or you can regard it as a point on the Google sphere when you are 
        about to use the Mercator formulas. 

B)   Alternatively, we could close our eyes hard and say: "there is no sphere in Sphere Mercator".   
        EPSG has (reluctantly) defined a map projection method they call 

                "Mercator (1SP) (Spherical)", with coord. op. method code 9841, 

     which is a different method from the two ellipsoidal projections "Mercator (1SP)" with coord. op. code 9804   
     and "Mercator (2SP)" with coord. op. code 9805. 
     For the spherical formulas, EPSG just refers to Snyder: "Map Projections: A Working Manual".   
     The trouble is that Snyder's formulas use the parameter R for the spherical radius, and EPSG refuses to 
        say how to get an R out of an ellipsoid (so they cannot allow an ellipsoid datum to be associated with 
        a spherical Mercator).   
     But they _could_ have said: if the datum is ellipsoidal, R should be taken to be the equatorial radius.   
     If they had done so, then "Mercator (1SP) (Spherical)" can be regarded as a mathematical function 
     that maps a p oint on the reference ellipsoid directly to the plane.  If you see the formulas as a black box, 
     you don't have to think of any sphere: it is enough if the formulas define a function that is continuous and 
     invertible. 

> My objection (well, one of my objections) is the implicit expectation that one can do relative 
> computations (whatever one does on a map) on a spherical Mercator and "the resulting lat/long 
> coordinates are intended to be treated as WGS84 after that" (in Frank's paraphrasing of what   
> the Google Maps model implies).  That's not true.   

Oh yes. You _can_ compute on the projected plane, unproject, and treat the result as WGS84 after that.   
The result may not be exactly what you wanted, but it wouldn't be so with an ellipsoid projection, either.   
For example, you wanted to go sqrt(2) * 100 km towards northeast.  All right, if you do so by your two 
methods, you get two different results. If you instead do it by following a geodetic route on the ellipsoid, 
starting towards northeast, and going sqrt(2) * 100 km on the ground, you would get a third result. And if 
you did it by following a rhumb line on the ellipsoid in the same way, you would get a fourth result.   

Computations in the projected plane simply do not agree exactly with ellipsoid distances and angles. 
(Except if you are lucky.) 

Best regards, 

-- 
Mikael Rittri 
Carmenta AB 
Box 11354 
SE-404 28 Göteborg 
Visitors: Sankt Eriksgatan 5 
SWEDEN 
Tel: +46-31-775 57 37 
Mob: +46-703-60 34 07 
mikael.rittri at carmenta.com 
www.carmenta.com 

[I am not not quoting all of Noel Zinn's letter here.] 

_______________________________________________ 
Proj mailing list 
Proj at lists.maptools.org 
http://lists.maptools.org/mailman/listinfo/proj 

_______________________________________________ 
Proj mailing list 
Proj at lists.maptools.org 
http://lists.maptools.org/mailman/listinfo/proj 

Tis the season to save your money! Get the new AOL Holiday Toolbar for money saving offers and gift ideas. 
_______________________________________________ Proj mailing list Proj at lists.maptools.org http://lists.maptools.org/mailman/listinfo/proj 
_______________________________________________ Proj mailing list Proj at lists.maptools.org http://lists.maptools.org/mailman/listinfo/proj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20081201/c1757bc1/attachment.html>