[postgis-users] NAD conversion problem

[Don]

Peter N. Schweitzer wrote:
> 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
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.

Thanks.