QGIS » QGIS Application

There was a similar ticket #10137 specific to GRASS and R but it was closed.

IF I open that layer, i do not see it as having the EPSG 3763 CRS. Instead, it has user defined one

If I set the CRS manually to 3763, then I can run algorithms, and the output has the same one. I tried with QGIS algorithms and SAGA ones, and it seems to work fine

Ok now I understand the problem. Doesn't look easy to fix.

The problem is that, when you set the CRS like that, and is not in the layer (not saved), when a backend like SAGA or GRASS opens that layer, it will not know about that assigned CRS. There is no way of passing it, it will take it from the layer itself.

A solution might be to let SAGA/GRASS/etc create a new layer in the CRS that it can found in the layer, and then assign to the result the same CRS as the input, but that will not work always (some algorithms might change the CRS, other might need the correct one to create the resulting layer...)

I will try to, at least, set a way of warning is that is the case.

The warning you propose seems reasonable to me. Something like this could be shown: "The CRS of the input layer does not match any of those included in the CRS database".

Also, the missing towgs84 parameters problem exists, as Giovanni Manghi stated, and it affects R and GRASS. With QGIS tools and SAGA it is ok I think.

Victor Olaya wrote:

Ok now I understand the problem. Doesn't look easy to fix.

The problem is that, when you set the CRS like that, and is not in the layer (not saved), when a backend like SAGA or GRASS opens that layer, it will not know about that assigned CRS. There is no way of passing it, it will take it from the layer itself.

A solution might be to let SAGA/GRASS/etc create a new layer in the CRS that it can found in the layer, and then assign to the result the same CRS as the input, but that will not work always (some algorithms might change the CRS, other might need the correct one to create the resulting layer...)

I will try to, at least, set a way of warning is that is the case.

Hi Victor,
is a very early Processing version (it was still SEXTANTE as a plugin under QGIS 1.8), there wasn't such issue with layers with a proper CRS definition (not layers with a CRS defined manually): running a GRASS alg on them returned an output with the very same CRS as the input.

I imported a shapefile on ETRS89 PT TM06 to R (standalone, not via QGIS), did some processing and exported it back to shapefile. When I imported it in QGIS, it was loaded with a custom CRS that was in fact ETRS89 but with no towgs parameters.

I believe that it's either an R problem, caused by writeOGR() inability of writing the +towgs84 parameters. Or QGIS is too picky and doesn't recognize ETRS89 unless it has the +towgs84.

Note that the definition of ETRS89 PT TM06 doesn't have +towgs84 parameters:

http://spatialreference.org/ref/epsg/3763/proj4/

Filipe Dias wrote:

I imported a shapefile on ETRS89 PT TM06 to R (standalone, not via QGIS), did some processing and exported it back to shapefile. When I imported it in QGIS, it was loaded with a custom CRS that was in fact ETRS89 but with no towgs parameters.

I believe that it's either an R problem, caused by writeOGR() inability of writing the +towgs84 parameters. Or QGIS is too picky and doesn't recognize ETRS89 unless it has the +towgs84.

so it seem an R problem. QGIS is not "too picky". QGIS uses proj4 definitions (that includes towgs84 parameters for many crs) and that is ok, because this way datum transformations are precise, unlike what happen in other gis packages like arcgis, where the same CRSs are transformed without towgs84 parameters and this usually means very inprecise transformations.

So GRASS seems still affected, and as I said it was working ok in a past Processing release.

Note that the definition of ETRS89 PT TM06 doesn't have +towgs84 parameters:

http://spatialreference.org/ref/epsg/3763/proj4/

that does not means a lot (in the context of this issue).

I found that the issue with +towgs84 parameters has been raised on the R side, but the developers have decided not change anything. See their reasons here:

http://permalink.gmane.org/gmane.comp.lang.r.geo/16119

It seems the problem is only with GRASS then.

It partially affects also GDAL/OGR tools: for example if you specify in an explicit way (for example with the proper ogr2ogr parameter) the output CRS then the output gets the CRS as it should, with the towgs84 string included. If you don't (and so let ogr2ogr use the input crs for the output) then the output gets the right crs, but stripped of the towgs84 string.

see also #14499

My guess is that the issue is related to this one:
https://trac.osgeo.org/grass/ticket/3048
(GRASS does not write AUTHORITY parameter (the EPSG code) to GeoTIFFs, thus QGIS makes a guess where it takes the first matching CRS (the ID number of the assigned EPSG code is lower than the original), I presume...).