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/>