[postgis-users] NAD conversion problem
Peter N. Schweitzer
pschweitzer at usgs.gov
Mon Sep 28 06:39:06 PDT 2009
Mark Cave-Ayland wrote:
> Peter N. Schweitzer wrote:
>>>> 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.
>>> 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.
>> I think I may have encountered this when converting data that are
>> 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
>> @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!
> 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
> 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));
psql> select ST_AsEWKT(ST_Transform(PointFromText('POINT(77.55 39.09)',4267),4269));
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 N. Schweitzer (MS 954, U.S. Geological Survey, Reston, VA 20192)
(703) 648-6533 FAX: (703) 648-6252 email: pschweitzer at usgs.gov
More information about the postgis-users