[Proj] Re: "Double ellipsoid" case?

[strebe]

Noel:

>My physical geodesy argument is that since WGS84 is a best fit to the geoid
>and since the Google Sphere is a terrible fit to the geoid no matter how you
>orientate it, using the Google Sphere obviates reference to the WGS84 datum... 

To which I reply, the original information from the WGS84 datum is all recoverable from the plane coordinates. Therefore, whether they used the Google Sphere, the WGS84 ellipsoid, or a potato or an icosahedron, so long as the WGS84 coordinates are recoverable, nothing got obviated.

>My geometric geodesy argument would be that geodesic direct and inverse
>computations would get different results on the WGS84 ellipsoid and the GS
>no matter how you map the WGS84 graticule onto the GS graticule.  This is an
>indictment of the use of the GS, since WGS84 computations better represent
>physical reality.  No one has suggested geodesic computations on the GS in
>this thread, but the implicit association of the GS with WGS84 by Google
>regrettably risks that abuse.

Geodesic computations should be performed in spherical coordinates, in which case, again, how those coordinates got projected does not matter so long as the spherical coordinates (on WGS84 ellipsoid) are recoverable. Google does not talk about the "Google Sphere" as far as I can tell; there is no such terminology turned up by a Web search. The specification is clear: geodetic data are given in WGS84 coordinates. I do not see how the projection method encourages anyone to make geodesic computations against the sphere.

Let me defend that. In order for the Google Map projection to encourage someone to choose the Google Sphere for geodesic calculations, the person would:

(a) Have to know the projection method; otherwise they would not even be cognizant of the Google Sphere, since it is part of the projection, not the datum from whence coordinates were supplied;

(b) Realize there is even a Google Sphere to be cognizant of, since it is never explicitly mentioned or promoted;

(c) Understand there is a difference between ellipsoidal calculations and spherical calculations for distance, and need the precision of the former;

(d) And still choose the Google Sphere for these geodesic calculations.

I have to suppose the intersection of (a), (b), (c), and (d) is... nobody.

>My appeals to conventional practice are even more compelling in my view, though
>you may disagree.

No; I agree. This is your strongest argument. 

>For example, ED50 geodesic direct and inverse computations and ED50 map
>projections are computed _only_ on the International ellipsoid.  Why?
>Computation on the ellipsoid of a datum’s least-squares adjustment provides (by
>definition) the best conformation with physical reality and the convention of
>doing so protects us from ignorant mistakes.  We all (I believe) follow this
>practice everywhere in the world (except in our use of Google Maps).  The risk
>to conventional practice introduced by Google is not progress.

I agree it is not progress in geodesy. Yet neither do I see it as any practical problem or as backsliding in geodesy. Those who need to perform computations will click a button, and they will receive their computations. I particularly do not agree that the Google Map projection will encourage mistakes. You insist people will interpret the Google Sphere as the datum. I do not believe that. It's just part of the projection calculus. It is a convenient short-cut that some engineers made in order to achieve what they wanted cheaply within acceptable bounds of error. What they wanted was rapid calculations retaining near-conformality so that they could use the same projection mathematics everywhere without introducing visible distortion in large-scale maps. They succeeded. That is the enterprise of engineering.

And, by the way, they knew what they were doing. They knew they were using not-quite-conformal mathematics and they knew they were doing something unorthodox. Those were acceptable trade-offs to them. The slander heaped upon them in an earlier e-mail was simply slander. No, they are not geodesists, photogrammetrists, or cartographers, but they never represented themselves as any of those, and the problems they were solving were not problems of geodesy or photogrammetry anyway. They were problems of mathematical cartography, and their solution achieved its goals.

>So, one thing is certain (and has already been stated in this thread), and that
>is that the Google Maps projection cannot be called the Mercator. 

Agreed, certainly with respect to large-scale mapping. For small-scale, well... nobody has coordinate data in spherical datums anyway, so what Google is doing is the de facto standard, even though it is not strictly Mercator.

>Mikael quantified the maximum angular distortion as 0.2 degrees.  At this point
>I’ll have to agree with Cliff that this is retrograde cartography.

At which point I will disagree. There is no use in this context for strict conformality, which is anyway largely a geodetic concern rather than a cartographic concern. Google is not solving geodetic problems and is not causing geodetic problems; therefore it makes no sense to take them to task for violating geodetic practices. There is no "retrograde cartography" going on here, just a rather mundane and obvious variant of a well-known map projection. Cartography has always been about compromises. Did Google pick optimal compromises in their projection choice? It sure seems like it.

Regards,
— daan Strebe


On Dec 2, 2008, at 7:31:14 AM, "Noel Zinn" <ndzinn at comcast.net> wrote:
From:   "Noel Zinn" <ndzinn at comcast.net>
Subject:    [Proj] Re: "Double ellipsoid" case?
Date:   December 2, 2008 7:31:14 AM PST
To: "'PROJ.4 and general Projections Discussions'" <proj at lists.maptools.org>
daan, Mikael, Cliff, and others,

 

Thanks for your persistence.  Indeed, clarifying our terminology will help.  For me the Google Sphere (GS) is simply an ellipsoid with an eccentricity squared of zero and semi-major axis (a) equal to the semi-major axis of the WGS84 ellipsoid.  In this case the semi-minor axis (b) equals the semi-major axis. 

 

Now, the Google Sphere can have both geodetic and cartographic applications.  That distinction is admittedly confusing in this thread.  I react viscerally to the introduction of the GS into the WGS84 datum as a geodetic abomination.  You and Mikael see the GS as merely an intermediate stage in a total projection method (which is non-conformal and, therefore, not the Mercator projection, and about which you are both defensive).  Cliff sees the GS as both bad geodesy and as bad cartography.  Frankly, I agree with Cliff.  I also accept Richard’s admonition to keep it civil.

 

So, before moving on to the cartography, I’ll briefly recap my geodetic objections.  My physical geodesy argument is that since WGS84 is a best fit to the geoid and since the Google Sphere is a terrible fit to the geoid no matter how you orientate it, using the Google Sphere obviates reference to the WGS84 datum (in my opinion). 

 

My geometric geodesy argument would be that geodesic direct and inverse computations would get different results on the WGS84 ellipsoid and the GS no matter how you map the WGS84 graticule onto the GS graticule.  This is an indictment of the use of the GS, since WGS84 computations better represent physical reality.  No one has suggested geodesic computations on the GS in this thread, but the implicit association of the GS with WGS84 by Google regrettably risks that abuse.

 

My appeals to conventional practice are even more compelling in my view, though you may disagree.  For example, ED50 geodesic direct and inverse computations and ED50 map projections are computed _only_ on the International ellipsoid.  Why?  Computation on the ellipsoid of a datum’s least-squares adjustment provides (by definition) the best conformation with physical reality and the convention of doing so protects us from ignorant mistakes.  We all (I believe) follow this practice everywhere in the world (except in our use of Google Maps).  The risk to conventional practice introduced by Google is not progress.

 

Now, on to the cartography.  Having reread Mikael’s postings I appreciate (and accept) his and daan’s perspective that this is a cartographic – and not a geodetic – issue.  The WGS84 datum can underlie this (unfortunate) two-stage projection used by Google Maps (Mikael’s alternative A).  Regarding Mikael’s alternative B, I’ll have to study the EPSG Mercator methods first before commenting.  And regarding daan’s interpretation that only one "ellipsoid" involved on the projection side, and that is the "Google Sphere", I don’t see it yet.  I stated previously that the spherical Mercator projection is intuitively conformal.  The ellipsoidal Mercator is conformal over a range of eccentricity squared values and there is no reason that that range shouldn’t include zero (the sphere) while maintaining conformality.  But first there is the non-conformal mapping from the WGS84 ellipsoid to the Google Sphere before the Mercator equations are applied.  So, one thing is certain (and has already been stated in this thread), and that is that the Google Maps projection cannot be called the Mercator.  It’s something else.  Mikael quantified the maximum angular distortion as 0.2 degrees.  At this point I’ll have to agree with Cliff that this is retrograde cartography.  Quoting Cliff, “using equivalent spheres in 19th and early 20th century cartography was an attempt to simplify ellipsoidal computations” and quoting Mikael, “the situation is similar to the French truncated Lambert Conformal Conic, which is not exactly conformal, and is a different projection than the true Lambert Conformal Conic”.  My question is, Why are we doing this in the 21st century?!?  This is retrograde cartography even if (no, especially if) the explanation is computational efficiency (in light of the “clouds” of computers maintained by Google).  Google had an opportunity to expose a wide audience to good geodetic and cartographic practice, but instead Google is exposing that audience to malpractice (in my opinion).  Yes, this is a judgment. And daan will respond that it works for their purposes.  I’m not so sure.  Google Maps is being used for lots of creative purposes encouraged by Google.  I believe that some user will stumble due to the poor choices made by Google.  Perhaps that can be documented in another thread. 

 

Regards and thanks for the great discussion,

Noel Zinn

 

 

 

 

 

_______________________________________________
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/20081203/efbd7bb6/attachment.html>