[Proj] RE: "Double Ellipsoid" error, reproduction

Sun Dec 7 20:10:59 PST 2008

daan,

Your objection constitutes a valid perspective, as we agreed.  I have a
different perspective.

The fact that the original geographic coordinates are recoverable through a
known, rigorous process does not support your case.  The geographic
coordinates of the original datum are always recoverable with a reverse
transformation from the geographicals of the transformed datum (well, except
for the 10-parameter Molodensky-Badekas, which is almost invertible with
negligible discrepancies).  Thats why consistent use of the same
transformation is more important than switching to a more accurate
transformation as new empirical evidence comes in.  

But you make a strong point in that There is nothing empirical; no
information is lost; and there is no error, at least in the mathematical
sense.  On the other hand, my experience is replete with naïve users
switching ellipsoids with zero geocentric offsets and getting into trouble.
This is risky behavior that should be discouraged in my perspective (working
in an industry that is already risky).  But your statement is technically
correct.  Furthermore, this ellipsoid switch in the first stage of Google
Maps Projection (GMP) is not a transformation of the 7-parameter of the
similarity type (Helmert, Bursa Wolf), which is conformal, at least in ECEF
(XYZ) space.  We have already established that this ellipsoid switch is the
cause of the non-conformality in the GMP.  

However, I take issue with your statement that Google have simply defined a
map projection.  Any defined map projection should have defined
distortions, even non-conformal projections.  I demonstrated how a user can
extract geodesic distances from grid coordinates and point scale factors
using Simpsons Approximation.  Thats the way most surveyors work (I
believe), not using (recovered) geographicals and geodesic computations,
though we may agree thats the best route.  What user knows to take the
WGS84 ratio of rho and nu (the radii of curvature in the meridian and prime
vertical) with the Equatorial radius and apply those to the spherical
Mercator point scales in order to find the real distortions in GMP?  If
Google havent defined that they havent defined a map projection.  If they
have, Id appreciate a reference.

These issues are buried in the noise for small scale maps, as you have
mentioned.  But the novelty of GMP is my concern, and that is that these
undocumented distortions are present in large scale maps that might be used
for real work in the field.  

We have different perspectives.  On one hand, GMP is just another projection
in the universe of possible projections (which is true).  On the other hand,
GMP is risky (Id rather say deviant) cartographic behavior (which is also
true).  

Thanks for catching my lapse,

Noel

  _____  

From: proj-bounces at lists.maptools.org
[mailto:proj-bounces at lists.maptools.org] On Behalf Of strebe
Sent: Sunday, December 07, 2008 8:09 PM
To: PROJ.4 and general Projections Discussions
Subject: [Proj] RE: "Double Ellipsoid" error, reproduction

Noel, I object to this characterization:

______

Map conversions (geographical
to grid) are merely mathematical mappings that are (theoretically) without
empirical error. Except - and this is my objection in this thread
heretofore - except when the ellipsoid is changed and a datum transformation
is implicitly coupled with a map conversion.

______

As we discussed, the original geographic coordinates are recoverable through
a known, rigorous process. There is nothing empirical; no information is
lost; and there is no error. There is not even a good reason to state that
the datum has changed in the case of Google Maps. They have simply defined a
map projection of WGS84 that is not conformal.

Regards,

 daan Strebe

On Dec 7, 2008, at 8:30:09 AM, "Noel Zinn" <ndzinn at comcast.net> wrote:

From:

"Noel Zinn" <ndzinn at comcast.net>

Subject:

RE: [Proj] "Double Ellipsoid" error, reproduction

Date:

December 7, 2008 8:30:09 AM PST

To:

"'PROJ.4 and general Projections Discussions'" <proj at lists.maptools.org>

Gerald,

The input and output of datum transformations are geographical coordinates.
Some methods of datum transformation (e.g. NADCON, NTv2, multiple regression
equations) work in geographicals and ellipsoid parameters are not required.
Other methods of datum transformations (e.g. 3 through 7 parameter
similarity, Helmert, Bursa-Wolf, 10-parameter Molodensky-Badekas) require a
transit through geocentric Cartesian, Earth-Centered Earth-Fixed (ECEF)
coordinates for which ellipsoid parameters are required. Datum
transformation parameters are always empirically derived and spatially
variant and, therefore, always contain error. Map conversions (geographical
to grid) are merely mathematical mappings that are (theoretically) without
empirical error. Except - and this is my objection in this thread
heretofore - except when the ellipsoid is changed and a datum transformation
is implicitly coupled with a map conversion.

So, the answers to your questions are (1) true and (2) false (in some
cases).

You are absolutely correct that there is no LAW about what a cartographer
does, limited by his or her own imagination, but there is a physical reality
for those who have an interest in conforming to it as closely as possible.
The best fit between physical reality and geographical coordinates is
defined by the ellipsoid in which the datum's least-squares adjustment of
survey data (collected in the real world, not in pixel space) was done.
Change the ellipsoid and the quality of the fit deteriorates (even in a
datum transformation and especially in a map conversion). I already
demonstrated in this thread that Google Maps Projection grid coordinates
bear an undocumented relationship with physical reality for the casual user.

Regards,
Noel

-----Original Message-----
From: proj-bounces at lists.maptools.org
[mailto:proj-bounces at lists.maptools.org] On Behalf Of Gerald I. Evenden
Sent: Sunday, December 07, 2008 9:25 AM
To: PROJ.4 and general Projections Discussions
Subject: Re: [Proj] "Double Ellipsoid" error, reproduction

I find this thread so incredible confusing I have tried to stay out of it 
entirely but I have one, maybe two questions:

I thought the basic detail operations of datum conversion were done in 
geographic data space (latitude-longitude) or perhaps x-y-z. That is, you 
have to have the data in geographic space to do the datum conversion 
calculation. True or False?

Also, ellipsoid factors are not part of the datum conversion as long as the 
data is in geographic coordinates: True or False?

If the above is true, what does the ellipsoid values have to do with
anything? 
That is a rhetorical question and the answer is obviously: nothing.

The question of the ellipsoid parameters only comes up when dealing with
data 
in Cartesian coordinates which need to be transformed back to geographic 
coordinates for datum transformation. The ellipsoid values are only a
factor 
in de-projecting the points.

The ellipsoid chosen for the Cartesian projection is probably a capricious
and 
arbitrary choice of the people who created the projected data in the first 
place. I know of no LAW that requires someone to choose a particular 
ellipsoid purely because of the datum of the data. The plotter may not have

any idea as to the datum of the data.

If the issue is simply two completely separate operations--- datum
conversion 
and ellipsoid-projection--- then what is all the discussion about???

What I am arguing is that the use of the ellipsoid parameters and datum 
conversion are two completely separate issues. Thus the problem discussed
in 
this thread is merely an issue finding the correct ellipsoid to get data
back 
into geographic coordinates, doing a datum conversion, and selecting an 
arbitrary a new ellipsoid for the target display map.

-- 
The whole religious complexion of the modern world is due
to the absence from Jerusalem of a lunatic asylum.
-- Havelock Ellis (1859-1939) British psychologist
_______________________________________________
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/20081207/13052278/attachment.html>