[postgis-users] NAD conversion problem

Sat Jan 29 14:23:43 PST 2011

Stefan,

Our apologies.  We'll clarify the instructions.

The batch script doesn't copy the files in the share/contrib folder.  I'm
debating if it should or not, part of me thinks it should but most of me
thinks not since people often have newer versions of those.

For windows install, the nad shift files are hard-coded to first look in
share/contrib/postgis as you probably guessed.

I guess our fear was if you were installing on an existing PostgreSQL with
another version of PostGIS, we really didn't want to override that folder.

If anyone else has thoughts on the matter, please let us know.  At anyrate
we should clarify the instructions.

Thanks,
Regina and Leo
http://www.postgis.us

-----Original Message-----
From: postgis-users-bounces at postgis.refractions.net
[mailto:postgis-users-bounces at postgis.refractions.net] On Behalf Of Stefan
Keller
Sent: Saturday, January 29, 2011 4:33 PM
To: PostGIS Users Discussion
Cc: Frank Warmerdam
Subject: Re: [postgis-users] NAD conversion problem

Hi,

I'm having problems with grid shift files and I suspect it's an installation
or compilation-config. problem:

This works:
# SELECT ST_AsText(ST_Transform('SRID=900913;POINT(977705
5981192)'::geometry, 21781))
But this...
# SELECT ST_AsText(ST_Transform('SRID=900913;POINT(977705
5981192)'::geometry, 4326))
.. gives following error:
> FEHLER:  transform: couldn't project point (977705 5.98119e+006 0): 
> failed to load NAD27-83 correction file (-38)
> HINT:  PostGIS was unable to transform the point because either no grid
shift files were found, or the point does not lie within the range for which
the grid shift is defined. Refer to the ST_Transform() section of the
PostGIS manual for details on how to configure PostGIS to alter this
behaviour.

I installed Postgres 9.1alpha and PostGIS 2.0 on Windows XP (experimental
binaries) using the makepostgisdb.bat ( from
http://postgis.refractions.net/download/windows/pg91/experimental/postgis/po
stgis-pg91-binaries-2.0.0svn.zip).
Below you see the contents of srid=900913 in my spatial_ref_sys  table
(should be the most recent).

That's what I observed: Looking at the contents of this zip there is a
directory ".\share\contrib\postgis\proj". But looking at makepostgisdb.bat
this directory (and its content including files calles nad*) is ignored.
There is consequently also no proj files under program files bin, lib, share
(e.g. C:\Program Files\PostgreSQL\9.1alpha1\ ). Under linux you wrote
elsewhere that the appropriate location of these files should be
/usr/local/share/proj and /usr/share/proj.

=> How can I make this transformation EPSG:900913 => 4326 work under
Windows?

=> To me, either .\share\contrib\postgis\proj should be deleted from .zip
delivery (because it's compiled into dll?)
     or makepostgisdb.bat should install/copy this proj directory somewhere
into %PGBIN% or %PGLIB%.

Yours, S.

---
SELECT srid, auth_name, auth_srid, proj4text, srtext FROM spatial_ref_sys
WHERE srid=900913; 900913;"spatialreferencing.org";900913;"+proj=merc
+a=6378137
+b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +units=m +k=1.0 
+nadgrids=@null +no_defs";"PROJCS["Popular Visualisation CRS /
Mercator (deprecated)",GEOGCS["Popular Visualisation
CRS",DATUM["Popular_Visualisation_Datum",SPHEROID["Popular
Visualisation
Sphere",6378137,0,AUTHORITY["EPSG","7059"]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY
["EPSG","6055"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree
",0.01745329251994328,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","4055"]],UN
IT["metre",1,AUTHORITY["EPSG","9001"]],PROJECTION["Mercator_1SP"],PARAMETER[
"central_meridian",0],PARAMETER["scale_factor",1],PARAMETER["false_easting",
0],PARAMETER["false_northing",0],AUTHORITY["EPSG","3785"],AXIS["X",EAST],AXI
S["Y",NORTH]]"

---

2009/9/28 Frank Warmerdam <warmerdam at pobox.com>:
> Peter N. Schweitzer wrote:
>>
>> 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.
>
> Peter,
>
> Yes, this is the expected behavior of including null in a list of 
> nadgrids. It is a fallback for quietly doing nothing if no other 
> matching grid is found.  BTW the @ prefix means it's ok for the grid 
> to not be found at all.   So if you wanted conus to be used for the 
> continental US, and do nothing outside that region you could use 
> +nadgrids=conus, at null while +nadgrids=@conus, at null means if the conus 
> grid does not exist it is ok to do nothing everywhere.
>
>>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!
>
> OK, as long as you understand the potential for error involved.
>
> Best regards,
> --
> ---------------------------------------+------------------------------
> ---------------------------------------+--------
> I set the clouds in motion - turn up   | Frank Warmerdam, 
> warmerdam at pobox.com light and sound - activate the windows | 
> http://pobox.com/~warmerdam and watch the world go round - Rush    | 
> Geospatial Programmer for Rent
>
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
_______________________________________________
postgis-users mailing list
postgis-users at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users