[Proj] WGS84 to Sphere Inconsistency Between Proj Versions

Faron Anslow fanslow at eos.ubc.ca
Thu Aug 21 23:00:08 EDT 2008

Frank Warmerdam wrote:
> Faron,
> In PROJ 4.6.0 and later the cs2cs command (and pj_transform()) will
> no longer attempt to apply any datum shift or change of ellipsoid
> transformation unless both the source and destination coordinate system
> have meaningful datum definitions provided (either +towgs84 or 
> +nadgrids).
Hi Frank,

This makes sense to me and explains the difference between versions. I 
would guess that the version of proj that matlab uses and that the mex 
file links against when "-l proj" is given is an older version of proj.4.

The question then is if it is more correct to not have the datum shift 
applied (and get the values I get from cs2cs as specified earlier) or to 
have the datum shift applied and get the value with the very negative 
elevation and different northing and eastings?

>> I suspect the problem is that documented in the FAQ, which requires 
>> the addition of +nadgrids=@null to the proj command.  However, when I 
>> add this to the cs2cs call, the results don't change.  When I add it 
>> to the mex call, the mex file crashes (not set up to handle the @null 
>> I guess).  Our question is which result is the correct one?  We 
>> suspect that a big change in elevation should be expected when 
>> switching from the WGS84 ellipsoid to the sphere.  cs2cs from proj 
>> 4.4 installed on another machine gives results that agree with our 
>> mex file.
>> Even stranger is that when we compile the mex file with the line:
>> mex Work/Code/Matlab_tools/cs2cs_proj4.c /usr/lib/libproj.a
>> instead of:
>> mex -l proj /home/fanslow/Work/Code/Matlab_tools/cs2cs_proj4.c
> I can only conclude that when you link against the static library
> you get one version, while the other link command is using a shared
> library and you end up picking up a different version of libproj.so.
> It isn't easy to deduce your build configuration, but basically I
> believe this comes down to the announced change of behavior between
> PROJ 4.5 and PROJ 4.6.
> Best regards,

I agree as above.  Using "-l proj" links to the matlab mapping toolbox 
library, which probably is older than the library I compiled a few days ago.

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

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?


Post Doctoral Researcher
Department of Earth and Ocean Sciences
The University of British Columbia
6339 Stores Road
Vancouver, British Columbia
Canada, V6T 1Z4

604 822 3063 

More information about the Proj mailing list