Bug report #5702

GRASS output is not georeferenced

Added by Markus Metz about 8 years ago. Updated about 5 years ago.

Status:Closed
Priority:High
Assignee:Victor Olaya
Category:Processing/GRASS
Affected QGIS version:2.4.0 Regression?:No
Operating System: Easy fix?:No
Pull Request or Patch supplied:No Resolution:not reproducable
Crashes QGIS or corrupts data:No Copied to github as #:15227

Description

The GRASS backend uses a temporary location without CRS (xy location). The output is therefore not georeferenced: shapefiles in tempdata have no *.prj file and GeoTIFFs no embedded CRS info. With regard to vector output, the -e flag of v.out.ogr does not have any effect because the location is a xy location. This can be fixed by the user with "Save as..." or "Set layer CRS".

It would be more comfortable if the output would already be georeferenced. This could be done by creating a second temporary location during import, using the CRS of the input data, i.e. [r.in.gdal|v.in.ogr] location=<name_of_new_location>, then switch to this location and proceed as before. The second temporary location will have the CRS of the input data and will use this CRS for export.

evora.zip (229 KB) Giovanni Manghi, 2012-12-16 03:55 PM

History

#1 Updated by Paolo Cavallini about 8 years ago

  • Assignee set to Victor Olaya

#2 Updated by Paolo Cavallini about 8 years ago

  • Category set to 59

#3 Updated by Victor Olaya over 7 years ago

  • Status changed from Open to Resolved

Should be fixed now

#4 Updated by Giovanni Manghi over 7 years ago

  • Status changed from Resolved to Closed

seems solved to me, please reopen if necessary.

#5 Updated by Giovanni Manghi over 7 years ago

  • Priority changed from Normal to High
  • Status changed from Closed to Reopened

at the end seems still true, for example with v.buffer as the .prj file is not created. May be other tools are affected.

#6 Updated by Victor Olaya over 7 years ago

  • Status changed from Reopened to Feedback

I have just tried v.buffer, and the result has a prj file. One question: does your input data has projection information?? I have noticed that there are problems with GRASS if you use data with no projection, and just using the "Set layer CRS" command in QGIS solves it. Maybe if the layer has no CRS, SEXTANTE should take the project CRS, assuming it has the same one.

#7 Updated by Giovanni Manghi over 7 years ago

Victor Olaya wrote:

I have just tried v.buffer, and the result has a prj file. One question: does your input data has projection information?? I have noticed that there are problems with GRASS if you use data with no projection, and just using the "Set layer CRS" command in QGIS solves it. Maybe if the layer has no CRS, SEXTANTE should take the project CRS, assuming it has the same one.

Hi Victor, I have tested with a couple of vectors, with a proper .prj file. Sample attached.

#8 Updated by Giovanni Manghi almost 7 years ago

  • Status changed from Feedback to Open

still true on qgis 2.0.1

#9 Updated by Giovanni Manghi almost 6 years ago

  • Project changed from 78 to QGIS Application
  • Category deleted (59)
  • Affected QGIS version set to 2.4.0
  • Crashes QGIS or corrupts data set to No

#10 Updated by Giovanni Manghi almost 6 years ago

  • Category set to Processing/GRASS

#11 Updated by Paolo Cavallini about 5 years ago

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.

#12 Updated by Giovanni Manghi about 5 years ago

  • Resolution set to fixed/implemented
  • Status changed from Open to Closed

the original issue seems to not be anymore a problem (since a long to tell the truth) while the missing towgs84 parameters in the outputs is still an issue, see #11884

#13 Updated by Giovanni Manghi about 5 years ago

  • Resolution changed from fixed/implemented to not reproducable

Also available in: Atom PDF