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: [email protected]
<http://geology.usgs.gov/peter/>
_______________________________________________
postgis-users mailing list
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
