[Proj] WGS84 to Sphere Inconsistency Between Proj Versions
Mikael Rittri
Mikael.Rittri at carmenta.com
Tue Aug 26 10:27:40 EDT 2008
Clifford J Mugnier wrote:
> ________________________________
> From: proj-bounces at lists.maptools.org [mailto:proj-bounces at lists.maptools.org] On Behalf Of Clifford J Mugnier
> Sent: den 25 augusti 2008 18:03
> To: PROJ.4 and general Projections Discussions
> Subject: RE: [Proj] WGS84 to Sphere Inconsistency Between Proj Versions
>
>
> Absolute spatial positions between disparate datums
> are lost when using datum-specific coordinates in a
> single spherical projection.
Sorry, I don't understand that sentence, either.
> I suggest you read some of my past columns, in
> particular "The Basics of Datums." This is not an
> appropriate venue to get into a detailed tutorial
> on geometric geodesy and it's historical foundations.
Thanks for the advice; I have read some of your columns,
but I had overlooked that one. However, now that I have read
it, I am no wiser. There is no mention of spherical projections
there.
Well, since you say datums and spherical projections don't
go together, it stands to reason that you wouldn't mention
spherical projections in a column about datums.
> In regards to your logic, I'll leave the rationalizations to you.
> What I said stands as is.
>
> C. Mugnier
Certainly. As I said, I respect your expertise. That's why I am
eager to understand what you mean.
About my logic, my intention was not to convince you that
you were wrong in a matter of geodesy. I merely hoped that if I
exposed the details of my own amateur reasoning, you would be able
to pinpoint some detail and say: "THAT's where you are wrong, Mikael."
I am sorry if it was all nonsense.
By the way, that's why I quoted Hillel, but perhaps it was
obscure: "The shamefast is not apt to learn", because he is too
shy to expose his ignorance by asking questions. In order to learn,
I was trying to expose my ignorance --- not my arrogance.
There was a related post from Melita Kennedy in June, by the way:
MK> The Mercator-based coordinate system used by Google Maps can be thought of in
MK> two ways.
MK>
MK> 1) It uses a sphere with radius=6378137.0 m. Sent to Mercator, hopefully, the
MK> code is smart enough to use the spherical equations.
MK> 2) It uses WGS84 with spherical Mercator equations.
MK>
MK> [--- text deleted ---]
MK>
MK> Melita
MK> ESRI, Inc.
(Quoted from http://lists.maptools.org/pipermail/proj/2008-June/003434.html).
I think that (2) corresponds to my way of thinking. I suppose you would say
that (1) is the only correct view.
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
________________________________
From: proj-bounces at lists.maptools.org on behalf of Mikael Rittri
Sent: Mon 25-Aug-08 10:26
To: PROJ.4 and general Projections Discussions
Subject: RE: [Proj] WGS84 to Sphere Inconsistency Between Proj Versions
Dear Mr. Mugnier,
you wrote
>When diddling with spherical projections, the concept of "DATUM" is entirely inappropriate.
which made me quite confused, because
1) I think what you wrote is absurd, and
2) I know well that you are an expert in geodesy.
But Hillel said, "the shamefast is not apt to learn", so let me go on.
I suppose you require more properties of a geodetic datum than I care about.
For me, a geodetic datum is essentially a way to georeference a map (or at least
to georeference the graticule on the map.) Surely you are not saying that if a map
uses a spherical projection, then its graticule cannot be georeferenced.
I have also been wondering why the EPSG people, when describing the web Mercator,
are careful to say that the geodetic datum is not WGS84 but something spherical
that is not a true datum.
As I see it, the projection machinery has to treat the earth as a sphere, while the
datum shift machinery has to treat it as an ellipsoid. And why not? In Carmenta Engine,
the Mercator class has a switch that lets you choose between ellipsoidal and spherical
formulas. So the projection can ignore the flattening of the ellipsoid, but the datum shift
machinery will not.
Are you (and EPSG) reasoning like this:
(1.) all projections must be implemented by ellipsoidal formulas, so
(2.) the only way to emulate spherical formulas is to supply an earth
model that is a sphere from the beginning; and no proper datum
can be spherical.
?
If so, then I agree that (2) follows from (1), and I agree that proper datums should
not be spherical. But I do not agree that (1) is true.
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
________________________________
From: proj-bounces at lists.maptools.org [mailto:proj-bounces at lists.maptools.org] On Behalf Of Clifford J Mugnier
Sent: den 22 augusti 2008 05:45
To: PROJ.4 and general Projections Discussions; PROJ.4 and general Projections Discussions
Subject: RE: [Proj] WGS84 to Sphere Inconsistency Between Proj Versions
When didling with spherical projections, the concept of "DATUM" is entirely inappropriate.
Cliff Mugnier
LOUISIANA STATE UNIVERSITY
________________________________
From: proj-bounces at lists.maptools.org on behalf of Frank Warmerdam
Sent: Thu 21-Aug-08 22:38
To: PROJ.4 and general Projections Discussions
Subject: Re: [Proj] WGS84 to Sphere Inconsistency Between Proj Versions
Faron Anslow wrote:
> I just ran this:
>
> cs2cs +proj=latlong +datum=WGS84 +to +proj=lcc +lat_1=50 +lat_2=50
> +lat_0=50 +lon_0=-107 +a=6371200.0000000000 +es=0.0 +f=0.0
> +towgs84=0,0,0 -r
>
> on:
> 70.933 -8.667
>
> and got:
> 2873633.37 4593659.18 -12148.43
>
> which is my original matlab answer and that from the old proj4.4. Now,
> the question is if forcing the datum shift with +towgs=0,0,0 is
> appropriate? Doesn't +towgs48 conflict with/override the spherical
> projection definition?
Faron,
I can't imagine any situation other than an effort to match old answers
where it makes sense to apply a plain lat/long on a sphere to lat/long on an
ellipsoid conversion the way this is doing.
If you want the lat/long values computed from the lcc projection based on
a sphere to treated as WGS84, then use +nadgrids=@null (or in 4.6.0 just
omit a datum specifier for the lcc projection). This is *likely* want
you want.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent
_______________________________________________
Proj mailing list
Proj at lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj
More information about the Proj
mailing list