Bug report #4611: Loss of projection/datum info during file conversion - QGIS Application - QGIS Issue Tracking

Bug report #4611

Loss of projection/datum info during file conversion

Added by Matt Kennedy almost 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:	worksforme
Crashes QGIS or corrupts data:	No	Copied to github as #:	14515

Description

QGIS 1.7.1 on Windows 7 64-bit installed from the standalone installer.

When saving .shp files as .mif files as EPSG:27700 (OSGB36), projection/datum information is lost. Consequently if the files are reloaded they have different parameters.

Currently EPSG 27700 is expressed in QGIS as:

Layer Spatial Reference System:
+proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717 +x_0=400000 +y_0=-100000 +ellps=airy +towgs84=446.448,-125.157,542.06,0.15,0.247,0.842,-20.489 +units=m +no_defs

However, when you save as a .mif file the parameters change to:
+proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717 +x_0=400000 +y_0=-100000 +ellps=WGS84 +towgs84=0,0,0,-0,-0,-0,0 +units=m +no_defs

Mif files using the same projection from MapInfo for instance (or even previous versions of QGIS) use this in the header of the file:

CoordSys Earth Projection 8, 79, "m", -2, 49, 0.9996012717, 400000, -100000

Whereas those exported using QGIS 1.7.1 now have:
CoordSys Earth Projection 8, 104, "m", -2, 49, 0.9996012717, 400000, -100000

In version 1.6.0 (standalone installer on windows xp 32-bit) projection information is retained when exporting. I assume this is because QGIS 1.6.0 has EPSG 27700 defined as:
+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

I seem to have a similar problem when using ogr2ogr with GDAL 1.8.1 (the towgs parms just disappear).

Matt

History

#1 Updated by Giovanni Manghi almost 13 years ago

Status changed from Open to Feedback

If you have the same problem from the command line with GDAL (the same GDAL version used in QGIS), then it is likely to be a GDAL problem. Please consider closing this ticket and filing one in the gdal trac.

#2 Updated by James Stott almost 13 years ago

This has been noted before.

#4271

If you open a MapInfo dataset in QGIS it comes in with a custom projection, not 27700 even though that is the one specified in the data. If I open it with On the fly reprojection turned on it shifts it. Turn on the fly off and it sits in the right place.

#3 Updated by Matt Kennedy almost 13 years ago

Ok I have delved a little deeper. GDAL seems to work. The reason I thought it didn't is because the shapefile I was converting from had been exported from QGIS 1.7.1 and also didn't have the correct parameters.

So it seems the problem as it stands is that the QGIS 1.7.1 does not export shapefiles correctly for EPSG27700 either. Version 1.6.0 saves them with the following .prj file:

PROJCS["Transverse_Mercator",GEOGCS["GCS_OSGB 1936",DATUM["D_OSGB_1936",SPHEROID["Airy_1830",6377563.396,299.3249646]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",49],PARAMETER["central_meridian",-2],PARAMETER["scale_factor",0.9996012717],PARAMETER["false_easting",400000],PARAMETER["false_northing",-100000],UNIT["Meter",1]]

Whereas QGIS version 1.7.1 saves them with this:
PROJCS["Transverse_Mercator",GEOGCS["GCS_Airy 1830",DATUM["D_unknown",SPHEROID["airy",6377563.396,299.3249753150316]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",49],PARAMETER["central_meridian",-2],PARAMETER["scale_factor",0.9996012717],PARAMETER["false_easting",400000],PARAMETER["false_northing",-100000],UNIT["Meter",1]]

So it seems QGIS version 1.7.1 is not picking up the datum and the spheroid parameters are slightly different.