[Proj] NAD problems on OSX 10.5 Leopard

[Ed McNierney]

William -

I wouldn't claim to be "definitive" but I get the same results as you report on PROJ 4.5.0 running on Windows, and with my interactive JavaScript coordinate/datum converter on the TopoZone site (which uses PROJ behind the scenes for datum shifts).

     - Ed

Ed McNierney
Chief Mapmaker
Demand Media / TopoZone.com
73 Princeton Street, Suite 305
North Chelmsford, MA  01863
ed at topozone.com
Phone: +1 (978) 251-4242
Fax: +1 (978) 251-1396
-----Original Message-----
From: proj-bounces at lists.maptools.org [mailto:proj-bounces at lists.maptools.org] On Behalf Of William Kyngesburye
Sent: Wednesday, January 16, 2008 10:43 AM
To: PROJ.4 and general Projections Discussions
Subject: Re: [Proj] NAD problems on OSX 10.5 Leopard

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


_______________________________________________
Proj mailing list
Proj at lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj