[Proj] "Double ellipsoid" case?
Mikael.Rittri at carmenta.com
Mon Dec 1 08:29:22 EST 2008
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!
> 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
> 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.)
SE-404 28 Göteborg
Visitors: Sankt Eriksgatan 5
Tel: +46-31-775 57 37
Mob: +46-703-60 34 07
mikael.rittri at carmenta.com
[I am not not quoting all of Noel Zinn's letter here.]
More information about the Proj