[postgis-users] NAD conversion problem

[Peter N. Schweitzer]

Richard Greenwood wrote:
> On Mon, Dec 8, 2008 at 12:19 PM, Peter N. Schweitzer
> <pschweitzer at usgs.gov> wrote:
>> Richard Greenwood wrote:
>>> On Thu, Dec 4, 2008 at 1:19 PM, Peter N. Schweitzer
>>> <pschweitzer at usgs.gov> wrote:
>>>> Hello,
>>>>
>>>> I have two PostgreSQL installations.  One uses 8.3.3 with PostGIS 1.3.3,
>>>> GEOS 3.0.1, and PROJ 4.6.1 (with proj-datumgrid-1.4).  With it I am able
>>>> to
>>>> run a command like
>>>>
>>>> update county set nad27_geom=ST_Transform(the_geom,4267);
>>>>
>>>> My newer installation uses 8.3.5 with PostGIS 1.3.4, GEOS 3.0.3, and
>>>> PROJ 4.6.1.  With this system I get the error message
>>>>
>>>> WARNING:  transform: -38 (failed to load NAD27-83 correction file)
>>>> ERROR:  transform: couldn't project point: -38 (failed to load NAD27-83
>>>> correction file)
>>>>
>>>> I know that proj-datumgrid-1.4.zip must be unzipped in the nad/
>>>> directory of proj-4.6.1 PRIOR to running configure.  I have done this.
>>>> I have also recompiled and reinstalled proj, GEOS, and PostGIS in that
>>>> order, running ldconfig at the end of each step.  The directory
>>>> /usr/local/share/proj on each of these systems is identical.
>>>>
>>>> I've tried recreating the database cluster, starting and stopping
>>>> the database instance, rebooting the machine, dropping and rebuilding
>>>> the spatial database, all to no avail.
>>>>
>>>> So I'm looking for some setting that I may have missed, some environment
>>>> variable, or some trick to tell libproj.so.0.5.5 where its transform
>>>> files should go.
>>>>
>>>> Both systems run Slackware 12.1.
>>>>
>>>> I'm at wit's end.  Any clues?
>>>>
>>>> Pete
>>> PROJ_LIB is an environment variable that points to the directory
>>> containing grid shift files and EPSG parameter files.
>>>
>>> The grid shift files are binary and platform specific. Is it possible
>>> that you are using Windows grid shift files on a Linux system?
>>>
>>> You could also rule out issues related to the different versions of
>>> Postgres and PostGIS on you two systems by testing at the command line
>>> with the cs2cs utility which is a part of Proj.
>> Rich,
>>
>> Thanks for your counsel.  The example using cs2cs from its documentation
>> worked the same on both systems, executed from the command line.
>>
>> I believe the grid shift files are slightly different, even though I
>> thought I had installed the same versions.  As a test, I copied the
>> /usr/local/share/proj directory from the older system (the one that
>> does the datum shift without complaint) to the newer one, and the
>> ST_Transform completes without error.  So I believe that is the source
>> of the problem.
>>
>> But there is only one link on http://trac.osgeo.org/proj/ for the datum
>> shift file package.  If the package is OS-specific I would
>> expect to see more than one.  So I am puzzled and worried that next
>> time I may face the same problem again.
>>
>> Peter
> 
> The files in http://svn.osgeo.org/metacrs/proj/trunk/proj/nad/ are
> ASCII. In the nad directory, you need to do:
>   ./configure
>   make
>   install
> to create the binary grid shift files that proj actually uses. (Proj
> doesn't read the ASCII files). And I'm not sure that the
> config-make-install of the proj program does the nad directory.
> 
> Rich

Many thanks to Rich and Dylan for helpful replies.

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",    "nadgrids=@conus, at alaska, at ntv2_0.gsb, at ntv1_can.dat",           
<                                                      "clrk66", 
---
> "NAD27",    "nadgrids=@conus, at alaska, at ntv2_0.gsb, at ntv1_can.dat, at null",
>                                                      "clrk66",

I don't recall when I added the ", at 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
-- 
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/>