[postgis-users] NAD conversion problem

[Mark Cave-Ayland]

Peter N. Schweitzer wrote:

(cut)

>>>> 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.
> 
> Frank,
> 
> I think I may have encountered this when converting data that are generally
> old (mostly based on pre-1980 maps) to NAD83.  I assume that those points
> located in North America would have used NAD27 (although mostly these are
> not high precision locations); for points located in other parts of the
> world, I have no datum information at all.  To make the PostGIS ingest
> happy, I typically tell shp2pgsql that the CRS of the shapefile is NAD27
> geographic in this case.
> 
> Most PostGIS functions operating on two geometries (ST_Intersects, for
> example) require the geometries to have the same SRID.  That's why I
> think I need to specify and keep track of the SRID for every table.
> 
> So my hypothesis--please help me understand how wrong this is--is that the
> @null has the effect of keeping proj going when I project a point that is
> not in the areas covered by the nad27-to-nad83 conversion tables.  I have
> to admit, as you probably suspect already, that I really don't know this
> stuff very well.  And since the data are not highly accurate in any case,
> the difference won't matter much in any analysis of the converted data.
> But this is what I'm thinking.  Your counsel would be welcome!
> 
> Peter

Note that with PostGIS 1.4 you can change this behaviour yourself by 
simply altering the spatial_ref_sys table entries directly if you 
require. This is probably a better solution than altering the PROJ.4 
behaviour for everything on your machine. See the 1.4 manual for more 
details: 
http://postgis.refractions.net/documentation/manual-1.4/ST_Transform.html.

I also agree with Frank that this is something that you want to be very 
careful with.


ATB,

Mark.

-- 
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063

Sirius Labs: http://www.siriusit.co.uk/labs