GRASS output is not georeferenced

[qgib]

Author Name: Markus Metz (@metzm)
Original Redmine Issue: 5702
Affected QGIS version: 2.4.0
Redmine category:processing/grass
Assignee: Victor Olaya

---

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 (Giovanni Manghi)

[qgib]

Author Name: Paolo Cavallini (@pcav)

---

• assigned_to_id was configured as Victor Olaya

[qgib]

Author Name: Paolo Cavallini (@pcav)

---

• category_id was configured as 59

[qgib]

Author Name: Victor Olaya (@volaya)

---

Should be fixed now

---

• status_id was changed from Open to Resolved

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

seems solved to me, please reopen if necessary.

---

• status_id was changed from Resolved to Closed

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

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

---

• priority_id was changed from Normal to High
• status_id was changed from Closed to Reopened

[qgib]

Author Name: Victor Olaya (@volaya)

---

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.

---

• status_id was changed from Reopened to Feedback

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

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.

---

• 5201 was configured as evora.zip

---

• evora.zip (Giovanni Manghi)

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

still true on qgis 2.0.1

---

• status_id was changed from Feedback to Open

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

• project_id was changed from 78 to 17
• category_id removed 59
• version was configured as 2.4.0
• crashes_corrupts_data was configured as 0

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

• category_id was configured as Processing/GRASS

[qgib]

Author Name: Paolo Cavallini (@pcav)

---

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.

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

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 #20098

---

• resolution was changed from to fixed/implemented
• status_id was changed from Open to Closed

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

• resolution was changed from fixed/implemented to not reproducable