[postgis-users] NAD conversion problem
Mark Cave-Ayland
mark.cave-ayland at siriusit.co.uk
Mon Sep 28 01:53:56 PDT 2009
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
More information about the postgis-users
mailing list