[Proj] WGS84 to Sphere Inconsistency Between Proj Versions

[Mikael Rittri]

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20080825/a59b23a1/attachment.html>