QGIS » QGIS Application

More useful info from the mailing list. See thread here:
http://lists.osgeo.org/pipermail/qgis-developer/2014-October/035153.html ===

The parameters are the same, so not really wrong. QGIS often does not recognize
similar projections when the name does not fit.

The only thing missing is the +wgs84 parameter from EPSG:23030:

+proj=utm +zone=30 +ellps=intl +towgs84=-87,-98,-121,0,0,0,0 +units=m +no_defs

exactly, in fact there is a shift due to that

Those parameters are often ignored in shapefiles, and QGIS does not find the right
EPSG code without them.

do you know if there is a ticket about this? it is unclear to me where exactly the
problem belongs:

GRASS is started with
g.proj -c proj4="+proj=utm +zone=32 +ellps=intl +towgs84=-87,-98,-121,0,0,0,0 +units=m +no_defs"

So the command line for GRASS is correct. From that point on, GRASS does not do any reprojections on the data, so GRASS is working ok. ED50 is not mentioned explicitely in the projection definition. I'm not sure if an EPSG-code can be given instead.

• the processing backend adding a (from QGIS point of view) malformed prj
• Processing itself not copying the right prj to the output
• QGIS failing to interpret valid parameters

The .prj that QGIS creates:

PROJCS["ED50_UTM_zone_32N",GEOGCS["GCS_European_1950",DATUM["D_European_1950",SPHEROID["International_1924",6378388,297]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",9],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",500000],PARAMETER["false_northing",0],UNIT["Meter",1]]

and the one from GRASS:
PROJCS["UTM_Zone_32_Northern_Hemisphere",GEOGCS["GCS_international",DATUM["D_unknown",SPHEROID["International_1924",6378388,297]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",9],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",500000],PARAMETER["false_northing",0],UNIT["Meter",1]]

with false names, but correct parameters, and no towgs84 in both cases. It seems that GRASS does some WKT guessing on its own, instead of just taking that of the input file to the output file.

But QGIS also creates a .qpj file with TOWGS84 parameters and the EPSG code:

PROJCS["ED50 / UTM zone 32N",GEOGCS["ED50",DATUM["European_Datum_1950",SPHEROID["International 1924",6378388,297,AUTHORITY["EPSG","7022"]],TOWGS84[-87,-98,-121,0,0,0,0],AUTHORITY["EPSG","6230"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","4230"]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",9],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",500000],PARAMETER["false_northing",0],UNIT["metre",1,AUTHORITY["EPSG","9001"]],AXIS["Easting",EAST],AXIS["Northing",NORTH],AUTHORITY["EPSG","23032"]]

This is for compatibility with shapefiles from ESRI, which never include TOWGS84 in the .prj

Maybe we should ask the processing dev to copy the .qpj from the input to the output file without further change. Or hand over the EPSG code on the GRASS command line unless a custom CRS is used.

I don't know if there is a ticket, and whether to address it to GRASS or processing. Perhaps to both.