On Tuesday 09 December 2008, Peter N. Schweitzer wrote: > Richard Greenwood wrote: > > On Mon, Dec 8, 2008 at 12:19 PM, Peter N. Schweitzer > > > > <[EMAIL PROTECTED]> wrote: > >> Richard Greenwood wrote: > >>> On Thu, Dec 4, 2008 at 1:19 PM, Peter N. Schweitzer > >>> > >>> <[EMAIL PROTECTED]> 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", "[EMAIL PROTECTED],@alaska,@ntv2_0.gsb,@ntv1_can.dat", > < "clrk66", > --- > > > "NAD27", "[EMAIL PROTECTED],@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
Strange. I have never modified that code before, and regularly get the correct output... I will post back with a similar example that causes PostGIS to throw the '-38' error. Cheers, Dylan -- Dylan Beaudette Soil Resource Laboratory http://casoilresource.lawr.ucdavis.edu/ University of California at Davis 530.754.7341 _______________________________________________ postgis-users mailing list [email protected] http://postgis.refractions.net/mailman/listinfo/postgis-users
