[postgis-users] SRID 27700 problem even with datum shift correction

Paul Ramsey pramsey at opengeo.org
Tue Feb 17 13:56:15 PST 2009


By saying @nadgrids=null you are implicitly saying "please don't try
to do spheroid conversions for me".  In cases where you are already in
WGS84, this is good. In other cases, it isn't. The @nadgrids hack was
invented by folks in North America, where their data is usually
already in NAD83, which is close enough to WGS84 that nobody cares.

P.

On Tue, Feb 17, 2009 at 5:49 AM, johnvb
<john.vanbreda at biodiverseit.co.uk> wrote:
>
> I've applied the following script to my database to install support for the
> Google Spherical Mercator projection, plus to fix the well known datum
> missing for SRID 27700:
> INSERT into spatial_ref_sys (srid, auth_name, auth_srid, srtext, proj4text)
> values (900913 ,'EPSG',900913,'GEOGCS["WGS 84", DATUM["World Geodetic System
> 1984", SPHEROID["WGS 84", 6378137.0,
> 298.257223563,AUTHORITY["EPSG","7030"]],
> AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich", 0.0,
> AUTHORITY["EPSG","8901"]], NIT["degree",0.017453292519943295],
> AXIS["Longitude", EAST], AXIS["Latitude", NORTH],AUTHORITY["EPSG","4326"]],
> PROJECTION["Mercator_1SP"],PARAMETER["semi_minor", 6378137.0],
> PARAMETER["latitude_of_origin",0.0], PARAMETER["central_meridian", 0.0],
> PARAMETER["scale_factor",1.0], PARAMETER["false_easting", 0.0],
> PARAMETER["false_northing", 0.0],UNIT["m", 1.0], AXIS["x", EAST], AXIS["y",
> NORTH],AUTHORITY["EPSG","900913"]] |','+proj=merc +a=6378137 +b=6378137
> +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m
> +nadgrids=@null +no_defs');
>
> -- Update the OSGB systems (easting/northing and lat long OSGB36) so they
> correctly use the OSGB36 datum
> UPDATE spatial_ref_sys SET proj4text = '+proj=longlat +ellps=airy
> +datum=OSGB36 +no_defs' WHERE srid=4277;
> UPDATE spatial_ref_sys SET proj4text = '+proj=tmerc +lat_0=49 +lon_0=-2
> +k=0.999601 +x_0=400000 +y_0=-100000 +ellps=airy +units=m +no_defs
> +datum=OSGB36' WHERE srid=27700;
>
> Now, even with this correction I can demonstrate a problem with the 27700
> SRID by using the following SQL:
>
> select '27700 to 900913 (incorrect)',
> st_astext(st_transform(st_geomfromtext('POINT(400000
> 100000)',27700),900913))
> union
> select '27700 to 4326 then 900913 (correct)',
> st_astext(st_transform(st_transform(st_geomfromtext('POINT(400000
> 100000)',27700),4326),900913))
>
> This shows 2 different results, one by transforming the point from 27700 to
> 900913, then another by converting via 4326. The conversion via 4326 seems
> to be correct, but the other conversion is wrong in a similar fashion to the
> error I'd expect if the datum shift was not working. The output I get is:
> "27700 to 4326 then 900913 (correct)";"POINT(-222791.172749668
> 6585914.69501315)"
> "27700 to 900913 (incorrect)";"POINT(-222638.981586547 6585815.32217342)"
>
> Any ideas why this discrepancy occurs? I'm using PostGIS 1.3.3 installed
> using the Application Stack
> Builder on Windows, against PostgreSQL 8.3.
> --
> View this message in context: http://www.nabble.com/SRID-27700-problem-even-with-datum-shift-correction-tp22056338p22056338.html
> Sent from the PostGIS - User mailing list archive at Nabble.com.
>
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>



More information about the postgis-users mailing list