[postgis-users] NAD conversion problem

[Frank Warmerdam]

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",   
>> "nadgrids=@conus, at alaska, at ntv2_0.gsb, at ntv1_can.dat",          
>> <                                                      "clrk66", ---
>>> "NAD27",    "nadgrids=@conus, at alaska, at ntv2_0.gsb, at ntv1_can.dat, at null",
>>>                                                      "clrk66",
>> I don't recall when I added the ", at 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, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent