Raster incorrectly reprojected to OSGB(27700) using QGIS [closed]

Question

I am using Ubuntu 12.04, QGIS 1.8.0, GDAL/OGR 1.7.3 and GEOS 3.2.2

Open a Spatialite db with OS Mastermap poly layer (EPSG:27700);
Add OpenLayers Plugin (1.0) from QGIS offical repository;
Add a Google Satellite layer (EPSG:3857) and make OS poly fills transparent;
Zoom & drag map a bit till it 'settles down' - then both aligned nicely;
Make poly layer not visible and save map as image (jpg + jpgw);
Add saved jpg back in as a layer (EPSG:3857) - still aligned;
Reproject (warp) jpg layer from EPSG:3857 to a EPSG:27700 Gtiff;
Add this Gtiff layer - no longer aligned but shifted about 6m North.

(On the fly CRS transformation is enabled)

I've had this issue before with the unstable flavour of UbuntuGIS QGIS, so went back to the stable & all was ok. This time I'm getting the 'shift' in the stable UbuntuGIS QGIS and no amount of wiping out the libraries (with Synaptic) & reinstalling has so far got rid of this 'shift'.

---

No problem reproducing the error (see comment by @underdark), but some more digging might narrow the issue a bit more.

The proj4 CRS projection string for OSGB/27700 in GDAL1.9.1 is:

+proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717 +x_0=400000 +y_0=-100000 +ellps=airy +towgs84=375,-111,431,0,0,0,0 +units=m +no_defs

The same thing in GDAL1.7.3 is:

+proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717 +x_0=400000 +y_0=-100000 +ellps=airy +datum=OSGB36 +units=m +no_defs

Even though QGIS is reporting the CRS as 27700 with the same proj4 string as the earlier GDAL1.7.3 it's probably using the later GDAL1.9.1 parameters for the reprojection behind the scenes. That would be fine if the image lined up after reprojection - but it doesn't.

To test a step further I created a QGIS user-defined CRS with the same projection parameters as the earlier GDAL version, and then reprojected with this - everything now lines up fine.

Are the EPSG:27700 projection parameters the likely suspect in the later GDAL (which QGIS is using) - or am I barking up the wrong tree?

Answer 1

There was a lot of discussion on that lately:

OSGB36 to WGS84 reprojection 'error'

http://osgeo-org.1560.n6.nabble.com/OSGB-coordinates-to-WGS84-lat-lon-problem-td4965339.html

https://stackoverflow.com/questions/1426941/proj-4-library-and-osgb36

If you want it very exact, use the +nadgrids and .gsb file mentioned. Here I gave some command line examples: How to reproject a raster file in QGIS with datum transformation?

If you want your data to fit to each other, always use the same +towgs84 instead of +datum. In your case, update the GDAL to 1.9.2.

For clarification: the ellipsoids airy and WGS84 do not match exactly. Therefore the +towgs84 parameters were invented. But these even change across the country. The +nadgrids takes this into account.

---

Just to explain a bit deeper:

EPSG:27700 is originally only a definition for the projection and ellipsoid used. Datum shift transformations from one ellipsoid to another are listed seperately by EPSG, with their own EPSG codes. There are several transformations available from OSB1936 to WGS84, depending on the region or wanted accuracy. These are:

EPSG:1195 Accuracy: 21m
+towgs84=375,-111,431
used by GDAL 1.9.1,Qgis Lisboa/Master +towgs84:

EPSG:1196 Accuracy 10m
England
+towgs84=371,-112,434

EPSG:1197 Accuracy 21m
England, Wales, Isle of Man
+towgs84=371,-111,434

EPSG:1198 Accuracy 18m
Scotland
+towgs84=384,-111,425

EPSG:1199 Accuracy 35m
Wales
+towgs84=370,-108,434

EPSG 1314: Accuracy 2m 
+towgs84=446.448,-125.157,542.060,0.1502,0.2470,0.8421,-20.4894
used in proj +datum=OSGB1936
used in GDAL up to Version 1.7.3

EPSG:5339: Accuracy 0,03m
+nadgrids=OSTN02_NTv2.gsb

the official grid datum can be obtained here: http://www.ordnancesurvey.co.uk/business-and-government/help-and-support/navigation-technology/os-net/ostn02-ntv2-format.html

The three-parameter-transformations were published by NIMA in the last century calculated from measuring of a handfull of satellite stations, while the seven parameters are published by Ordnance Survey more recently.

So depending on the GDAL version a raster is georeferenced with, you might get an offset, or might not.

---

relief is on the way:

http://trac.osgeo.org/gdal/changeset/25589

So there is a good chance that the seven-parameter transformation will be back in the next QGIS version.