[Proj] NAD problems on OSX 10.5 Leopard

[William Kyngesburye]

Sorry to keep responding to myself...

On Jan 16, 2008, at 9:08 AM, William Kyngesburye wrote:

>> On the other side, though, with the current extra bytes, the  
>> fseek() in nad_ctable_load() doesn't seem to be skipping over those  
>> bytes, so they are read as part of the data.  Could it be due to  
>> sizeof(ct) used in nad2bin, but sizeof(struct CTABLE) used in  
>> nad_ctable_load()?  Or an fseek bug?
>>
>
> So, is sizeof(struct CTABLE) supposed to be the size including the  
> *cvs pointer?  If so, then it's a bug (OSX at least) in sizeof.  But  
> the pj_malloc(sizeof(struct CTABLE)) in nad_ctable_init() seems to  
> be working properly.
>
> To make sure, how about:
>
> sizeof(&cd.id) + sizeof(&cd.ll) + sizeof(&cd.del) + sizeof(&cd.lim)
>
>>


no sizeof bug.  I was probably (still) misunderstanding datum  
transforms a bit, and the  latlong to latlong tests and utm27 to utm83  
tests, though the same, were still wrong. Now, with the writing of the  
NAD files leaving out the extra bytes, AND and reading in the nad_init  
seeking to the proper place with the above sizeof change, it's all  
consistent, and agrees with the Tiger 32bit-only transform:


$ 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
118d0'3.385"W	37d59'59.751"N 0.000

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

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


Is there a definitive way to verify this?  I'm basing the  
"correctness" of this by the NAD83 ticks on a USGS topo map.

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

"Those people who most want to rule people are, ipso-facto, those  
least suited to do it."

- A rule of the universe, from the HitchHiker's Guide to the Galaxy