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
_______________________________________________
Qgis-developer mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
