Frank Warmerdam wrote:
Don wrote:
Peter N. Schweitzer wrote:
I was able to trace the problem to a file in the proj source code.
in proj-4.6.1/src/pj_datums.c
87,88c87,88
< "NAD27",
"nadgri...@conus,@alaska,@ntv2_0.gsb,@ntv1_can.dat",
< "clrk66", ---
"NAD27", "nadgri...@conus,@alaska,@ntv2_0.gsb,@ntv1_can.dat,@null",
"clrk66",
I don't recall when I added the ",@null" to the nadgrids= line, but I
think it was in response to someone else's urging. And adding it to
the current source causes proj to correctly locate the conversion
files. I don't know whether this is a bug in proj or a peculiarity
of the systems where I've deployed it.
Thanks again for your help!
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
--
Peter N. Schweitzer (MS 954, U.S. Geological Survey, Reston, VA 20192)
(703) 648-6533 FAX: (703) 648-6252 email: pschweit...@usgs.gov
<http://geology.usgs.gov/peter/>
_______________________________________________
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users
