[Proj] "Double ellipsoid" case?

Mon Dec 1 06:53:11 PST 2008

Mikael, 

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 could 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 
        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 point 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 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20081201/9bb3c132/attachment.html>