Bug report #4271: British National Grid CRS incorrectly specified when exporting to MapInfo - QGIS Application - QGIS Issue Tracking

Bug report #4271

British National Grid CRS incorrectly specified when exporting to MapInfo

Added by Andy Harfoot over 13 years ago. Updated about 10 years ago.

Status:	Closed
Priority:	Normal
Assignee:	-
Category:	Projection Support
Affected QGIS version:	master	Regression?:	No
Operating System:		Easy fix?:	No
Pull Request or Patch supplied:	No	Resolution:	up/downstream
Crashes QGIS or corrupts data:	No	Copied to github as #:	14211

Description

From a layer in QGIS with a layer CRS specified as EPSG:27700 (British National Grid) and the project CRS set as the same, if the Save as command is run and a MIF or TAB file is saved (specifying the CRS as EPSG:27700), the resulting MapInfo file has a coordinate system set to be using the British National Grid Transverse Mercator projection, but the WGS84 datum rather than the OSGB36 one that is normally associated with the British National Grid. this has the effect of generating an offset in the exported data locations of approximately 100m.

This effect can be observed without requiring a copy MapInfo by viewing the contents of the MIF file in a text editor. The line beginning CoordSys should then read Earth Projection 8, 79 for BNG using OSGB36, but will read Earth Projection 8, 104 for BNG using WGS84.

I wondered if OGR was at fault, but running a TAB to MIF translation with ogr2ogr using British National Grid doesn't seem to give the same issue.

Running QGIS 1.7.0 on Windows 7 x64

History

#1 Updated by James Stott over 13 years ago

I also get the same problem running QGIS 1.8 (67dfd2e) on Windows XP,

#2 Updated by Giovanni Manghi about 13 years ago

Target version set to Version 1.7.4

#3 Updated by Paolo Cavallini over 12 years ago

Crashes QGIS or corrupts data set to No
Affected QGIS version set to master
Target version changed from Version 1.7.4 to Version 1.8.0

#4 Updated by ramon . over 12 years ago

A colleague pointed out behaviour matching this to me, except with the Australian Datums (GDA94 and ADG84) and associated projections (MGA94 and AMG84).

My colleague has 1.74 installed by the OSGeo method on Windows 7 (64-bit).

I've tested on the same platform (different computer), and on 1.9 and confirmed the behaviour.

The only major difference is that for me ogr2ogr does not work (1.74 and 1.9 currently use GDAL 1.9), and wondered if this bug might be related to http://trac.osgeo.org/gdal/ticket/481 ?

James and Andy, if you have time could you check that ogr2ogr is still be having as expected?