Re: [Qgis-developer] v.generalize in Processing: wrong output projection
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",50],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",50],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",50],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 Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] v.generalize in Processing: wrong output projection
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: * 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. -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] v.generalize in Processing: wrong output projection
Am 19.10.2014 09:31, schrieb 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",50],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",50],PARAMETER["false_northing",0],UNIT["Meter",1]] that is interpreted by QGIS as a custom projection (USER:17 - * 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 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] v.generalize in Processing: wrong output projection
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",50],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",50],PARAMETER["false_northing",0],UNIT["Meter",1]] that is interpreted by QGIS as a custom projection (USER:17 - * 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. -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html file:///tmp/processing/d12f7e0d4a7c8a6912550128a0d9/output.prj ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
