[Proj] NAD problems on OSX 10.5 Leopard

Frank Warmerdam warmerdam at pobox.com
Tue Jan 15 18:31:31 PST 2008


William Kyngesburye wrote:
> This is an odd one.  On OSX 10.5 (Leopard), as a 64bit binary PROJ/cs2cs 
> correctly translates betwen NAD27 and NAD83.  But, as a 32bit binary it 
> translates in the opposite direction.  The OSX 10.4 (Tiger) build 
> (32bits-only) also correctly translates datums (ie, it's the same as the 
> 64bit translation).
> 
> $ cs2cs +proj=latlong +datum=NAD27 +to +proj=latlong +datum=NAD83
> -118 38
> 118d0'3.385"W    37d59'59.751"N 0.000
> 
> $ arch -i386 cs2cs +proj=latlong +datum=NAD27 +to +proj=latlong 
> +datum=NAD83
> -118 38
> 117d59'59.748"W    38d0'3.385"N 0.000
> 
> 
> The Tiger binary, even running on Leopard gets the translation correct, 
> so I wonder if something is happening in the compilation.
> 
> long's can be trouble, since on 32bit OSX they are 32bit, but on 64bit 
> OSX they are 64bit.  Looking at nad2bin (and a few library sources), I 
> see that longs are used in the NAD tables (lam and phi), so the NAD 
> binary files are getting built with 64bit longs, then the 32bit PROJ is 
> trying to read 32bit longs.
> 
> Are the NAD tables meant to always be 64bit longs?  Should long long be 
> used instead, to guarantee 64bit longs, or maybe they should be configured?

William,

Pretty bizzare behavior.

The nadcon style datum shift files are expected to be platform specific and
that means a 32bit generated datum shift file cannot be used by 64bit
program safely (amoung other things).  I *suspect* this is at the root
of your problem.

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    | President OSGeo, http://osgeo.org




More information about the Proj mailing list