[Qgis-developer] v.generalize in Processing: wrong output projection

[Andre Joost]

Am 20.10.2014 08:45, schrieb Paolo Cavallini:
> Il 19/10/2014 11:30, Andre Joost ha scritto:
>
>> 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.

Greetings,
André Joost