[Proj] NAD problems on OSX 10.5 Leopard

Frank Warmerdam warmerdam at pobox.com
Tue Jan 15 21:31:31 EST 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?


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