Bug report #4271
British National Grid CRS incorrectly specified when exporting to MapInfo
| 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 about 13 years ago
I also get the same problem running QGIS 1.8 (67dfd2e) on Windows XP,
#2
Updated by Giovanni Manghi almost 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?
#5
Updated by Paolo Cavallini about 12 years ago
- Target version changed from Version 1.8.0 to Version 2.0.0
#6
Updated by Jürgen Fischer over 10 years ago
- Target version changed from Version 2.0.0 to Future Release - Lower Priority
#7
Updated by Giovanni Manghi about 10 years ago
- Resolution set to up/downstream
- Status changed from Open to Closed
seems an upstream issue