Don wrote:
Peter N. Schweitzer wrote:
I was able to trace the problem to a file in the proj source code.
in proj-4.6.1/src/pj_datums.c
87,88c87,88
< "NAD27",
"nadgri...@conus,@alaska,@ntv2_0.gsb,@ntv1_can.dat",
< "clrk66", ---
"NAD27", "nadgri...@conus,@alaska,@ntv2_0.gsb,@ntv1_can.dat,@null",
"clrk66",
I don't recall when I added the ",@null" to the nadgrids= line, but I
think it was in response to someone else's urging. And adding it to
the current source causes proj to correctly locate the conversion
files. I don't know whether this is a bug in proj or a peculiarity
of the systems where I've deployed it.
Thanks again for your help!
Peter
I recently had this problem with packages downloaded from the opensuse
repository. Once I hand built and installed proj with this "@null"
patch the problem went away.
Folks,
I have not followed this discussion closely, but I am pretty sure adding
@null at the end of the list just allows pj_transform() to "succeed"
if it does not find a transform file. That is, you are just masking
the fact that no datum shift file is found, and the final results will
be off by the amount of the datum shift - often a matter of hundreds of
meters for NAD27/NAD83 shifts.
Are you sure this is what you want?
In some applications it wouldn't matter (ie. weather scale work), but at
others it will completely invalidate your work spatially speaking.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent
_______________________________________________
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users
