[postgis-users] NAD conversion problem

[Peter N. Schweitzer]

Mark Cave-Ayland wrote:
> 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.

It looks to me like it does what I want.  Taking two points, one inside
and the other outside North America, I have

psql> select ST_AsEWKT(ST_Transform(PointFromText('POINT(-77.55 39.09)',4267),4269));
                      st_asewkt
-----------------------------------------------------
 SRID=4269;POINT(-77.5497126443548 39.0901066943327)
(1 row)


psql> select ST_AsEWKT(ST_Transform(PointFromText('POINT(77.55 39.09)',4267),4269));
               st_asewkt
-----------------------------------------
 SRID=4269;POINT(77.55 39.0900000009235)
(1 row)

If I recall correctly, before I added @null, if I executed the second query, 
I would get an error.

I have to say that datum transformations are almost as confusing and frustrating
as character encoding problems!

Peter
-- 
Peter N. Schweitzer (MS 954, U.S. Geological Survey, Reston, VA 20192)
(703) 648-6533  FAX: (703) 648-6252  email: pschweitzer at usgs.gov
<http://geology.usgs.gov/peter/>