v.generalize in Processing: wrong output projection

[Paolo Cavallini]

Hi all.
Applying v.generalize through Processing on data with prj:

PROJCS["ED50_UTM_zone_30N",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",-3],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",500000],PARAMETER["false_northing",0],UNIT["Meter",1]]

generates an output with a wrong prj:

PROJCS["UTM_Zone_30_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",-3],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",500000],PARAMETER["false_northing",0],UNIT["Meter",1]]

that is interpreted by QGIS as a custom projection (USER:100007 - * SR generato
(+proj=utm +zone=30 +ellps=intl +units=m +no_defs)).

Anyone confirms? It is not clear to me which part of the toolchain is to blame.
Should I open a ticket?

All the best.

[Andre Joost]

Post by Paolo Cavallini
PROJCS["ED50_UTM_zone_30N",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",-3],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",500000],PARAMETER["false_northing",0],UNIT["Meter",1]]
PROJCS["UTM_Zone_30_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",-3],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",500000],PARAMETER["false_northing",0],UNIT["Meter",1]]
that is interpreted by QGIS as a custom projection (USER:100007 - *
SR generato (+proj=utm +zone=30 +ellps=intl +units=m +no_defs)).

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

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

Greetings,
André Joost

[Paolo Cavallini]

The parameters are the same, so not really wrong. QGIS often does not recognize
similar projections when the name does not fit.
+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:
* 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
or?
thanks.

[Andre Joost]

Post by Paolo Cavallini

The parameters are the same, so not really wrong. QGIS often does not recognize
similar projections when the name does not fit.
+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

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.

Post by Paolo Cavallini
* 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