[Proj] NAD problems on OSX 10.5 Leopard

[William Kyngesburye]

On Jan 15, 2008, at 8:31 PM, Frank Warmerdam wrote:

> 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.

I poked around to try to understand it better.  The lam/laml/phi/phil  
that are longs, appear to be only used in reading the text source  
lla's.  The CTABLE that is written in binary form uses only doubles,  
floats and ints, which don't change between 32 and 64bit OSX.  At  
least, the number of bytes used doesn't change - would the binary  
format be different?  That doesn't make sense.

Comparing the binary files, on 64bits and 32bits, Tiger and Leopard:

64bit-Leo file
32bit-Tiger file
32bit-Leo file

The headers are all exactly the same - the ints and doubles for the  
lower-left coord, cell size, and grid size match in all files.  The  
floats for the conversion matrix don't match, immediately.  There are  
4 bytes in the 32bit files, and 8 bytes in the 64bit files, before the  
matrix that I can't account for.  After that the matrixes of floats  
match.  The calculated size of the matrix from the grid size matches  
the byte count after those mystery bytes.

Did I miss something in the CTABLE (pardon my ignorance here):

struct CTABLE {
	char id[MAX_TAB_ID]; /* ascii info */
	LP ll;      /* lower left corner coordinates */
	LP del;     /* size of cells */
	ILP lim;    /* limits of conversion matrix */
	FLP *cvs;   /* conversion matrix */
};

Is maybe the bulk fwrite of *cvs prepending something?  It looks like  
an integer of some sort.  And then the nad_init functions are reading  
them as part of the matrix float data.

So, I manually deleted those extra bytes.  Now 32bit and 64bit  
translations match.  And make more sense really (if I understand in  
right, datum transforms give me a headache) - when translating the  
datum of a latlong coordinate, the latlong doesn't actually change,  
it's the projected coordinate that changes.

$ cs2cs +proj=latlong +datum=NAD27 +to +proj=latlong +datum=NAD83
-118 38
118dW	38dN 0.000

$ arch -i386 cs2cs +proj=latlong +datum=NAD27 +to +proj=latlong  
+datum=NAD83
-118 38
118dW	38dN 0.000

Or, bad NAD file:

$ cs2cs +init=EPSG:26711 +to +init=EPSG:26911412199.39 4206081.09
412118.95	4206279.97 0.00

$ arch -i386 cs2cs +init=EPSG:26711 +to +init=EPSG:26911
412199.39 4206081.09
412208.85	4206391.01 0.00

and good NAD file:

$ cs2cs +init=EPSG:26711 +to +init=EPSG:26911
412199.39 4206081.09
412201.58	4206286.75 0.00

$ arch -i386 cs2cs +init=EPSG:26711 +to +init=EPSG:26911
412199.39 4206081.09
412201.58	4206286.75 0.00


I dug back into my ancient binaries and it's been like this since I  
started packaging PROJ and friends!

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"This is a question about the past, is it? ... How can I tell that the  
past isn't a fiction designed to account for the discrepancy between  
my immediate physical sensations and my state of mind?"

- The Ruler of the Universe