Bug report #11884
Processing generates outputs with no "+towgs84" parameters
Status: | Closed | ||
---|---|---|---|
Priority: | Severe/Regression | ||
Assignee: | Victor Olaya | ||
Category: | Processing/Core | ||
Affected QGIS version: | master | Regression?: | No |
Operating System: | Easy fix?: | No | |
Pull Request or Patch supplied: | No | Resolution: | duplicate |
Crashes QGIS or corrupts data: | No | Copied to github as #: | 20098 |
Description
Run "split vector layer" with the attached shapefile which is in ETRS89 PT TM06 (EPSG 3763). The resulting output has a custom CRS that is similar to ETRS89 but without the "+towgs84" parameters.
USER:100003 - * Generated CRS (+proj=tmerc +lat_0=39.66825833333333 +lon_0=-8.133108333333334 +k=1 +x_0=0 +y_0=0 +ellps=GRS80 +units=m +no_defs)
Related issues
History
#1 Updated by Giovanni Manghi about 10 years ago
- Category changed from Processing/QGIS to Processing/Core
- Subject changed from Split vector layer generates an output with no "+towgs84" parameters to Processing generates an output with no "+towgs84" parameters
It is not a specific issue of one tool, is a general issue in processing (it strips always the towgs parameter in outputs), and I agree that is pretty urgent to be fixed.
Anyway this ticket is duplicate of another one, that I cannot find now.
#2 Updated by Filipe Dias about 10 years ago
There was a similar ticket #10137 specific to GRASS and R but it was closed.
#3 Updated by Giovanni Manghi about 10 years ago
- Subject changed from Processing generates an output with no "+towgs84" parameters to Processing generates outputs with no "+towgs84" parameters
- Priority changed from Normal to Severe/Regression
- Target version changed from Future Release - High Priority to Version 2.8
Filipe Dias wrote:
There was a similar ticket specific to GRASS and R but it was closed
it was a regression then and so it is also a regression now.
#4 Updated by Victor Olaya about 10 years ago
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
#5 Updated by Filipe Dias about 10 years ago
- Subject changed from Processing generates outputs with no "+towgs84" parameters to Manually setting the crs has no effect - the outputs receive the original CRS rather then than the one set by the user
It seems the problem is different than the one I reported, sorry. The custom CRS of this shapefile is ETRS89 without the towgs84 parameters.
If you set this shapefile to ETRS89, store it using "save as", and then run split vector, the outputs have the correct CRS.
If you manually set the CRS to ETRS89 (without doing save as) and then run "split layer", the outputs have the same custom CRS as the original input.
The problem is that Processing doesn't read the manually selected CRS.
#6 Updated by Giovanni Manghi about 10 years ago
- Subject changed from Manually setting the crs has no effect - the outputs receive the original CRS rather then than the one set by the user to Processing generates outputs with no "+towgs84" parameters
it is a general issue, eventually only for some backends like GRASS (where it surely happens, probably also R), but indeed a general issue that applies to layer that have a proper CRS recognized by QGIS.
#7 Updated by Victor Olaya about 10 years ago
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.
#8 Updated by Filipe Dias about 10 years ago
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.
#9 Updated by Giovanni Manghi about 10 years ago
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.
#10 Updated by Filipe Dias almost 10 years ago
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:
#11 Updated by Giovanni Manghi almost 10 years ago
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:
that does not means a lot (in the context of this issue).
#12 Updated by Filipe Dias almost 10 years ago
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.
#13 Updated by Giovanni Manghi almost 10 years ago
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.
#14 Updated by Giovanni Manghi over 9 years ago
- Target version changed from Version 2.8 to Version 2.8.2
#15 Updated by Giovanni Manghi over 9 years ago
- Target version changed from Version 2.8.2 to Version 2.10
#16 Updated by Giovanni Manghi about 9 years ago
- Target version deleted (
Version 2.10)
#17 Updated by Giovanni Manghi over 8 years ago
see also #14499
#18 Updated by Stefan Blumentrath about 8 years ago
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...).
#19 Updated by Giovanni Manghi almost 8 years ago
- Status changed from Open to Closed
- Resolution set to duplicate
duplicate of #10137