Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GRASS/Processing outputs CRS mismatch #18596

Closed
qgib opened this issue Apr 29, 2014 · 43 comments
Closed

GRASS/Processing outputs CRS mismatch #18596

qgib opened this issue Apr 29, 2014 · 43 comments

Comments

@qgib
Copy link
Contributor

@qgib qgib commented Apr 29, 2014

Author Name: Paolo Cavallini (@pcav)
Original Redmine Issue: 10137
Affected QGIS version: 3.4.1
Redmine category:processing/grass


Apparently Processing, during the analyses starting from layers in a CRS with +towgs parameters (e.g. 23030) creates outputs with a similar projection, but without the parameters; a custom CRS is thus created, and the output does not align with the input.
This happens at least with GRASS and R backends.


Related issue(s): #20098 (relates), #25391 (duplicates)
Redmine related issue(s): 11884, 17494


@qgib
Copy link
Contributor Author

@qgib qgib commented Apr 30, 2014

Author Name: Giovanni Manghi (@gioman)


Confirmed here on master/ubuntu.

This is certainly a regression.

PS
It does not happen only for CRSs that may exist in two version, one with towgs84 and one not (ex: 3003 and 102091), but happens with all CRSs: in one original CRS has no equivalent version without towgs84 then the result will be a layer with a custom CRS automatically created by qgis.


  • version was changed from 2.2.0 to master
  • priority_id was changed from Normal to Severe/Regression
  • fixed_version_id was configured as Version 2.4
@qgib
Copy link
Contributor Author

@qgib qgib commented May 16, 2014

Author Name: Giovanni Manghi (@gioman)


Can you please check again, it does not seems to happen anymore.


  • status_id was changed from Open to Feedback
@qgib
Copy link
Contributor Author

@qgib qgib commented May 22, 2014

Author Name: Paolo Cavallini (@pcav)


Confirmed, it is OK here


  • status_id was changed from Feedback to Closed
  • resolution was changed from to fixed/implemented
@qgib
Copy link
Contributor Author

@qgib qgib commented Jun 7, 2015

Author Name: Giovanni Manghi (@gioman)


  • category_id was changed from 94 to Processing/Core
@qgib
Copy link
Contributor Author

@qgib qgib commented Feb 14, 2017

Author Name: leolami - (leolami -)


Hi all,
the problem is again present on the GRASS modules
QGIS 2.14.11 on Windows 10 but I think also in Linux

For example v.select

Regards


  • version was changed from master to 2.14.11
  • status_id was changed from Closed to Reopened
  • fixed_version_id was changed from Version 2.4 to Version 3.0
  • operating_system was changed from to Windows
@qgib
Copy link
Contributor Author

@qgib qgib commented Feb 27, 2017

Author Name: Giovanni Manghi (@gioman)


see also #20098

@qgib
Copy link
Contributor Author

@qgib qgib commented Feb 27, 2017

Author Name: Giovanni Manghi (@gioman)


  • operating_system was changed from Windows to
  • version was changed from 2.14.11 to 2.18.4
  • resolution was changed from fixed/implemented to
  • fixed_version_id was changed from Version 3.0 to Version 2.18
  • category_id was changed from Processing/Core to Processing/GRASS
@qgib
Copy link
Contributor Author

@qgib qgib commented Apr 30, 2017

Author Name: Giovanni Manghi (@gioman)


  • regression was configured as 1
@qgib
Copy link
Contributor Author

@qgib qgib commented Apr 30, 2017

Author Name: Giovanni Manghi (@gioman)


  • priority_id was changed from Severe/Regression to High
@qgib
Copy link
Contributor Author

@qgib qgib commented Apr 30, 2017

Author Name: Giovanni Manghi (@gioman)


  • easy_fix was configured as 0
@qgib
Copy link
Contributor Author

@qgib qgib commented May 5, 2017

Author Name: Giovanni Manghi (@gioman)


  • version was changed from 2.18.4 to 2.18.7
  • description was changed from Apparently Processing, during the analyses starting from layers in a CRS with +towgs parameters (e.g. 23030) creates outputs with a similar projection, but without the parameters; a custom CRS is thus created, and the output does not align with the input.
    This happens at least with GRASS and R backends. to Apparently Processing, during the analyses starting from layers in a CRS with +towgs parameters (e.g. 23030) creates outputs with a similar projection, but without the parameters; a custom CRS is thus created, and the output does not align with the input.
    This happens at least with GRASS and R backends.
  • status_id was changed from Reopened to Open
@qgib
Copy link
Contributor Author

@qgib qgib commented Jul 15, 2017

Author Name: Giovanni Manghi (@gioman)


  • version was changed from 2.18.7 to 2.18.10
@qgib
Copy link
Contributor Author

@qgib qgib commented Jul 25, 2017

Author Name: Giovanni Manghi (@gioman)


  • version was changed from 2.18.10 to 2.18.11
@qgib
Copy link
Contributor Author

@qgib qgib commented Nov 20, 2017

Author Name: Jürgen Fischer (@jef-n)


  • duplicated was configured as #25391
@qgib
Copy link
Contributor Author

@qgib qgib commented Feb 24, 2018

Author Name: Paolo Cavallini (@pcav)


  • assigned_to_id removed Victor Olaya
@qgib
Copy link
Contributor Author

@qgib qgib commented Feb 24, 2018

Author Name: Giovanni Manghi (@gioman)


  • version was changed from 2.18.11 to 3.0.0
@qgib
Copy link
Contributor Author

@qgib qgib commented Sep 5, 2018

Author Name: Giovanni Manghi (@gioman)


  • version was changed from 3.0.0 to 3.3(master)
@qgib
Copy link
Contributor Author

@qgib qgib commented Nov 15, 2018

Author Name: Alexandre Neto (@SrNetoChan)


  • version was changed from 3.3(master) to 3.4.1
@nyalldawson
Copy link
Collaborator

@nyalldawson nyalldawson commented May 22, 2020

Should not be an issue with proj 6 based builds. If it is, it's an issue in the 3rd party application instead of qgis.

@gioman
Copy link
Contributor

@gioman gioman commented Dec 24, 2020

we auto add and remove this term when needed, it should have no impact

@nyalldawson can you elaborate? the example here above seems to suggest that if there is "+type=crs" the CRS do not match the equivalent CRS as recognized by QGIS and so it shows "unkown".

Doesn't your findings confirm that this is an upstream issue? (Or at least, a question to ask upstream)

it seems so, but honestly I'm not totally sure. Just thinking out load here below:

I tried to import (in native GRASS) my sample data in the temp mapset/location created by QGIS when running GRASS tools from processing, and it fails

WARNING: Projection of dataset does not appear to match current location.

Location PROJ_INFO is:
name: unknown
ellps: grs80
proj: tmerc
lat_0: 39.6682583333333
lon_0: -8.13310833333333
k: 1
x_0: 0
y_0: 0
towgs84: 0,0,0,0,0,0,0
no_defs: defined

Dataset PROJ_INFO is:
name: ETRS89 / Portugal TM06
datum: etrs89
ellps: grs80
proj: tmerc
lat_0: 39.6682583333333
lon_0: -8.13310833333333
k: 1
x_0: 0
y_0: 0
towgs84: 0,0,0,0,0,0,0
no_defs: defined

ERROR: datum

this is why in QGIS we use the "-o" parameter in r.in.gdal (is to override the projection check, and use the mapset/location one instead). Anyway this has the effect that after exporting this raster (or one calculated from it) out from GRASS it has a CRS that does not exactly any as known by QGIS.

I don't see anything wrong done by QGIS, as it creates the temp location/mapset with the exact CRS of the input

+proj=tmerc +lat_0=39.6682583333333 +lon_0=-8.13310833333333 +k=1 +x_0=0 +y_0=0 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs

vs

g.proj -c proj4="+proj=tmerc +lat_0=39.6682583333333 +lon_0=-8.13310833333333 +k=1 +x_0=0 +y_0=0 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs"

but this has the effect of creating this CRS mismatch in outputs.

On the other hand when creating the mapset/location with the input CRS the projection reports as (by g.proj)

+proj=tmerc +lat_0=39.6682583333333 +lon_0=-8.13310833333333 +k=1 +x_0=0 +y_0=0 +no_defs +a=6378137 +rf=298.257222101 +towgs84=0.000,0.000,0.000 +type=crs +to_meter=1

but then outputting the raster generates one with a CRS that QGIS correctly matches the one of the input layer.

So I'm definitely puzzled. @neteler any idea? (note that the title of this ticket seems now outdated, a new description of the issue is here #18596 (comment))

mdt_clipped.zip

@neteler
Copy link
Contributor

@neteler neteler commented Dec 30, 2020

@gioman Testing it with GRASS GIS 7.8 (Fedora 33, for library versions see below) it looks as expected to me:

grass78 -c mdt_clipped.tif ~/grassdata/portugal_tm06 --exec g.proj -w
Starting GRASS GIS...
Creating new GRASS GIS location <portugal_tm06>...
Cleaning up temporary files...
Executing <g.proj -w> ...
PROJCS["ETRS89 / Portugal TM06",
    GEOGCS["ETRS89",
        DATUM["European_Terrestrial_Reference_System_1989",
            SPHEROID["GRS 1980",6378137,298.257222101,
                AUTHORITY["EPSG","7019"]],
            TOWGS84[0,0,0,0,0,0,0],
            AUTHORITY["EPSG","6258"]],
        PRIMEM["Greenwich",0,
            AUTHORITY["EPSG","8901"]],
        UNIT["degree",0.0174532925199433,
            AUTHORITY["EPSG","9122"]],
        AUTHORITY["EPSG","4258"]],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["latitude_of_origin",39.6682583333333],
    PARAMETER["central_meridian",-8.13310833333333],
    PARAMETER["scale_factor",1],
    PARAMETER["false_easting",0],
    PARAMETER["false_northing",0],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]],
    AXIS["Easting",EAST],
    AXIS["Northing",NORTH],
    AUTHORITY["EPSG","3763"]]
Execution of <g.proj -w> finished.
Cleaning up temporary files...

grass78 ~/grassdata/portugal_tm06/PERMANENT/ --exec g.version -rge
Starting GRASS GIS...
Cleaning up temporary files...
Executing <g.version -rge> ...
version=7.8.6dev
date=2020
revision=d92439f54
build_date=2020-12-27
build_platform=x86_64-pc-linux-gnu
build_off_t_size=8
libgis_revision=4ed00a6ed
libgis_date=2020-12-21T18:44:07+00:00
proj=6.3.2
gdal=3.1.4
geos=3.8.1
sqlite=3.34.0
Execution of <g.version -rge> finished.
Cleaning up temporary files...
@gioman
Copy link
Contributor

@gioman gioman commented Dec 30, 2020

Testing it with GRASS GIS 7.8 (Fedora 33, for library versions see below) it looks as expected to me

@neteler I have no doubts is correct. As you can see in my comments above replicating the whole import/process/export in native GRASS results in a layer that has no CRS issues when opened in QGIS. The same process in GRASS/Processing (using the same modules used in native GRASS, with basically the same parameters) creates an output that has a CRS that is correct but has a proj string that is slightly different from the original, causing QGIS recognize it as "unknown" that is not a big deal but also not ideal. The question/problem is to try understand why/where this happens.

@neteler
Copy link
Contributor

@neteler neteler commented Dec 30, 2020

... creates an output that has a CRS that is correct but has a proj string that is slightly different from the original, causing QGIS recognize it as "unknown" that is not a big deal but also not ideal. The question/problem is to try understand why/where this happens.

Well, since PROJ is undergoing dramatic changes, I believe that valid comparisons can only be done with identical PROJ versions. In your post I don't see which PROJ 6.y.z version you use (that may matter).

@gioman
Copy link
Contributor

@gioman gioman commented Dec 30, 2020

Well, since PROJ is undergoing dramatic changes, I believe that valid comparisons can only be done with identical PROJ versions. In your post I don't see which PROJ 6.y.z version you use (that may matter).

@neteler

QGIS version 3.16.2-Hannover QGIS code revision f1660f9
Compiled against Qt 5.12.8 Running against Qt 5.12.8
Compiled against GDAL/OGR 3.0.4 Running against GDAL/OGR 3.0.4
Compiled against GEOS 3.8.0-CAPI-1.13.1 Running against GEOS 3.8.0-CAPI-1.13.1
Compiled against SQLite 3.31.1 Running against SQLite 3.31.1
PostgreSQL Client Version 12.5 (Ubuntu 12.5-0ubuntu0.20.04.1) SpatiaLite Version 4.3.0a
QWT Version 6.1.4 QScintilla2 Version 2.11.2
Compiled against PROJ 6.3.1 Running against PROJ Rel. 6.3.1, February 10th, 2020
OS Version Ubuntu 20.04.1 LTS

GRASS 7.8.2 (newLocation):~ > g.version -rge
version=7.8.2
date=2019
revision=exported
build_date=2020-03-24
build_platform=x86_64-pc-linux-gnu
build_off_t_size=8
libgis_revision=00000
libgis_date="?"
proj=6.3.1
gdal=3.0.4
geos=3.8.0
sqlite=3.31.1
@neteler
Copy link
Contributor

@neteler neteler commented Dec 30, 2020

Now we need to know the differences between proj=6.3.1 (yours) and proj=6.3.2 (mine)...

I do not spot anything relevant there (not an expert, though).

BUT: you also use an oldish GRASS GIS Version (7.8.2 from 2019), missing some PROJ 6+ related fixes:

Maybe that's the reason?

@gioman
Copy link
Contributor

@gioman gioman commented Dec 30, 2020

I updated my GRASS:


g.version -rge
version=7.8.5
date=2020
revision=exported
build_date=2020-12-23
build_platform=x86_64-pc-linux-gnu
build_off_t_size=8
libgis_revision=2020-12-23T15:13:18+00:00
libgis_date=2020-12-23T15:13:18+00:00
proj=7.2.0
gdal=3.2.0
geos=3.9.0
sqlite=3.31.1

The result is the same. From within GRASS/Processing the outputs CRS reads as

+proj=tmerc +lat_0=39.6682583333333 +lon_0=-8.13310833333333 +k=1 +x_0=0 +y_0=0 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs +type=crs

out of native GRASS the same output has a CRS that reads as

+proj=tmerc +lat_0=39.6682583333333 +lon_0=-8.13310833333333 +k=1 +x_0=0 +y_0=0 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs

that extra " +type=crs" causes the mismatch.

@neteler
Copy link
Contributor

@neteler neteler commented Dec 30, 2020

I don't really know what's right, maybe @rouault could enlighten us?

@gioman gioman changed the title Processing stripping out +towgs params GRASS/Processing outputs CRS mismatch Dec 30, 2020
@rouault
Copy link
Contributor

@rouault rouault commented Dec 31, 2020

maybe @rouault could enlighten us?

I'm afraid I'm a bit lost in this thread. What is the question exactly ? " +type=crs" is added by PROJ >= 6 when exporting objects that are CRS. This is to distinguish from transformation pipelines.

@neteler
Copy link
Contributor

@neteler neteler commented Jan 1, 2021

Another test, again with proj=6.3.2, GRASS GIS 7.8.6dev, build_date=2020-12-27:

#  -j   Print projection information in PROJ.4 format
#  -f   Print 'flat' output with no linebreaks (applies to WKT and PROJ.4 output)
grass78 -c mdt_clipped.tif ~/grassdata/portugal_tm06 --exec g.proj -j
grass78 -c mdt_clipped.tif ~/grassdata/portugal_tm06 --exec g.proj -jf
Starting GRASS GIS...
Creating new GRASS GIS location <portugal_tm06>...
Cleaning up temporary files...
Executing <g.proj -jf> ...
+proj=tmerc +lat_0=39.6682583333333 +lon_0=-8.13310833333333 +k=1 +x_0=0 +y_0=0 +no_defs +a=6378137 +rf=298.257222101 +towgs84=0,0,0,0,0,0,0 +type=crs  +to_meter=1
Execution of <g.proj -jf> finished.
Cleaning up temporary files...

The expected +type=crs is there. I have no idea where it get's lost in QGIS/Processing...

@gioman
Copy link
Contributor

@gioman gioman commented Jan 1, 2021

I'm afraid I'm a bit lost in this thread. What is the question exactly ? " +type=crs" is added by PROJ >= 6 when exporting objects that are CRS. This is to distinguish from transformation pipelines.

@rouault I'll make here a resume (as noted above the issue changed slightly since this was filed).

In QGIS GRASS/Processing when we run some tool the output gets a CRS that is correct but that does not match 100% the one of the input layers, so QGIS shows "unknown" instead of showing exactly the CRS of the input (as far as I have understand this happens only when the input CRS has some towgs84 parameters).

Note: the original issue was about that GRASS/Processing was stripping altogether the towgs84 parameters from the output CRS, and this do not seems to the case anymore.

So for example if the input has the EPSG 3763 CRS

+proj=tmerc +lat_0=39.6682583333333 +lon_0=-8.13310833333333 +k=1 +x_0=0 +y_0=0 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs

the output from an operation in GRASS/Processing is

+proj=tmerc +lat_0=39.6682583333333 +lon_0=-8.13310833333333 +k=1 +x_0=0 +y_0=0 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs +type=crs

with the extra "+type=crs" causing the mismatch. This is not a big deal because from a user point of view do not change much, but is a bit of inconvenience as this new layers to do not show in QGIS with a precise (as shown by QGIS) CRS.This causes some confusion.

The question/doubt is about how/where this "+type=crs" gets added, as replicating in native GRASS the same exact operations that GRASS/Processing does, do not cause this problem.

GRASS/Processing imports automatically/on the fly the input(s) in a temp GRASS location/mapset, then process them and them exports them. An example of what happens under the hood in GRASS/Processing:

g.proj -c proj4="+proj=tmerc +lat_0=39.6682583333333 +lon_0=-8.13310833333333 +k=1 +x_0=0 +y_0=0 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs"

r.in.gdal input="/home/mdt_clipped.tif" band=1 output="rast_5fe32bdbc09365" --overwrite -o

g.region n=90778.1843088 s=54378.1843088 e=54963.0859278 w=10243.0859278 res=80.0

r.slope.aspect elevation=rast_5fe32bdbc09365 format="degrees" precision="FCELL" -a zscale=1 min_slope=0 slope=slope96d409769d4b468c93dac24f83d4e801 --overwrite

g.region raster=slope96d409769d4b468c93dac24f83d4e801
r.out.gdal -t -m input="slope96d409769d4b468c93dac24f83d4e801" output="/home/teste_qgis.tif" format="GTiff" createopt="TFW=YES,COMPRESS=LZW" --overwrite

This creates an output with a CRS that reads

+proj=tmerc +lat_0=39.6682583333333 +lon_0=-8.13310833333333 +k=1 +x_0=0 +y_0=0 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs +type=crs

that does do not match completely the one of the input data.

In native GRASS we can do the same steps (after having created and opened manually a location/mapset with a CRS that matches the one of the input data):

r.in.gdal input=/home/mdt_clipped.tif output=dem

r.slope.aspect elevation=dem@PERMANENT slope=slope                         

r.out.gdal input=slope@PERMANENT output=/home/teste_grass.tif format=GTiff

this creates an output that has a CRS

+proj=tmerc +lat_0=39.6682583333333 +lon_0=-8.13310833333333 +k=1 +x_0=0 +y_0=0 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs

that fully matches the one of the input data.

https://github.com/qgis/QGIS/files/5739277/mdt_clipped.zip

@gioman
Copy link
Contributor

@gioman gioman commented Jan 1, 2021

The expected +type=crs is there. I have no idea where it get's lost in QGIS/Processing...

@neteler it the other way... the original data CRS has not +type=crs while the output from GRASS/Processing has it. The output from native GRASS, following the same commands used in GRASS/Processing has not +type=crs.

@rouault
Copy link
Contributor

@rouault rouault commented Jan 1, 2021

I don't believe the presence/absence of +type=crs is the issue.
Looking at PROJ strings is not the best way to figure out the CRS as they are a lossy representation of it. Better look at the WKT representation as output by gdalinfo.
I would suspect that the issue might be that "+ellps=GRS80 +towgs84=0,0,0,0,0,0,0" must be used somewhere to instanciate a CRS, and this losses the fact the the datum is ETRS89.

@gioman
Copy link
Contributor

@gioman gioman commented Jan 2, 2021

@rouault thanks for the feedback.

result of gdalinfo on output from the GRASS

Driver: GTiff/GeoTIFF
Files: slope_grass.tif
Size is 559, 455
Coordinate System is:
PROJCRS["ETRS89 / Portugal TM06",
    BASEGEOGCRS["ETRS89",
        DATUM["European Terrestrial Reference System 1989",
            ELLIPSOID["GRS 1980",6378137,298.257222101,
                LENGTHUNIT["metre",1]]],
        PRIMEM["Greenwich",0,
            ANGLEUNIT["degree",0.0174532925199433]],
        ID["EPSG",4258]],
    CONVERSION["Portugual TM06",
        METHOD["Transverse Mercator",
            ID["EPSG",9807]],
        PARAMETER["Latitude of natural origin",39.6682583333333,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8801]],
        PARAMETER["Longitude of natural origin",-8.13310833333333,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8802]],
        PARAMETER["Scale factor at natural origin",1,
            SCALEUNIT["unity",1],
            ID["EPSG",8805]],
        PARAMETER["False easting",0,
            LENGTHUNIT["metre",1],
            ID["EPSG",8806]],
        PARAMETER["False northing",0,
            LENGTHUNIT["metre",1],
            ID["EPSG",8807]]],
    CS[Cartesian,2],
        AXIS["easting (X)",east,
            ORDER[1],
            LENGTHUNIT["metre",1]],
        AXIS["northing (Y)",north,
            ORDER[2],
            LENGTHUNIT["metre",1]],
    USAGE[
        SCOPE["Topographic mapping (medium scale)."],
        AREA["Portugal - mainland - onshore."],
        BBOX[36.95,-9.56,42.16,-6.19]],
    ID["EPSG",3763]]
Data axis to CRS axis mapping: 1,2
Origin = (10243.085927800000718,90778.184308800002327)
Pixel Size = (80.000000000000000,-80.000000000000000)
Metadata:
  AREA_OR_POINT=Area
  TIFFTAG_SOFTWARE=GRASS GIS 7.8.5 with GDAL 3.2.0
Image Structure Metadata:
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  (   10243.086,   90778.184) (  8d 0'44.27"W, 40d29' 8.70"N)
Lower Left  (   10243.086,   54378.184) (  8d 0'46.37"W, 40d 9'28.60"N)
Upper Right (   54963.086,   90778.184) (  7d29' 5.53"W, 40d29' 2.39"N)
Lower Right (   54963.086,   54378.184) (  7d29'16.79"W, 40d 9'22.35"N)
Center      (   32603.086,   72578.184) (  7d44'58.23"W, 40d19'16.60"N)
Band 1 Block=559x3 Type=Float32, ColorInterp=Gray
  Description = slope@PERMANENT
  NoData Value=nan

result of gdalinfo on output from the Processing/GRASS:

Driver: GTiff/GeoTIFF
Files: slope_qgis_grass.tif
       slope_qgis_grass.tif.aux.xml
Size is 559, 455
Coordinate System is:
BOUNDCRS[
    SOURCECRS[
        PROJCRS["unknown",
            BASEGEOGCRS["grs80",
                DATUM["unknown",
                    ELLIPSOID["Geodetic_Reference_System_1980",6378137,298.257222101,
                        LENGTHUNIT["metre",1,
                            ID["EPSG",9001]]]],
                PRIMEM["Greenwich",0,
                    ANGLEUNIT["degree",0.0174532925199433,
                        ID["EPSG",9122]]]],
            CONVERSION["Transverse Mercator",
                METHOD["Transverse Mercator",
                    ID["EPSG",9807]],
                PARAMETER["Latitude of natural origin",39.6682583333333,
                    ANGLEUNIT["degree",0.0174532925199433],
                    ID["EPSG",8801]],
                PARAMETER["Longitude of natural origin",-8.13310833333333,
                    ANGLEUNIT["degree",0.0174532925199433],
                    ID["EPSG",8802]],
                PARAMETER["Scale factor at natural origin",1,
                    SCALEUNIT["unity",1],
                    ID["EPSG",8805]],
                PARAMETER["False easting",0,
                    LENGTHUNIT["metre",1],
                    ID["EPSG",8806]],
                PARAMETER["False northing",0,
                    LENGTHUNIT["metre",1],
                    ID["EPSG",8807]]],
            CS[Cartesian,2],
                AXIS["easting",east,
                    ORDER[1],
                    LENGTHUNIT["metre",1,
                        ID["EPSG",9001]]],
                AXIS["northing",north,
                    ORDER[2],
                    LENGTHUNIT["metre",1,
                        ID["EPSG",9001]]]]],
    TARGETCRS[
        GEOGCRS["WGS 84",
            DATUM["World Geodetic System 1984",
                ELLIPSOID["WGS 84",6378137,298.257223563,
                    LENGTHUNIT["metre",1]]],
            PRIMEM["Greenwich",0,
                ANGLEUNIT["degree",0.0174532925199433]],
            CS[ellipsoidal,2],
                AXIS["geodetic latitude (Lat)",north,
                    ORDER[1],
                    ANGLEUNIT["degree",0.0174532925199433]],
                AXIS["geodetic longitude (Lon)",east,
                    ORDER[2],
                    ANGLEUNIT["degree",0.0174532925199433]],
            USAGE[
                SCOPE["Horizontal component of 3D system."],
                AREA["World."],
                BBOX[-90,-180,90,180]],
            ID["EPSG",4326]]],
    ABRIDGEDTRANSFORMATION["Transformation to WGS84",
        METHOD["Position Vector transformation (geog2D domain)",
            ID["EPSG",9606]],
        PARAMETER["X-axis translation",0,
            ID["EPSG",8605]],
        PARAMETER["Y-axis translation",0,
            ID["EPSG",8606]],
        PARAMETER["Z-axis translation",0,
            ID["EPSG",8607]],
        PARAMETER["X-axis rotation",0,
            ID["EPSG",8608]],
        PARAMETER["Y-axis rotation",0,
            ID["EPSG",8609]],
        PARAMETER["Z-axis rotation",0,
            ID["EPSG",8610]],
        PARAMETER["Scale difference",1,
            ID["EPSG",8611]]]]
Data axis to CRS axis mapping: 1,2
Origin = (10243.085927800000718,90778.184308800002327)
Pixel Size = (80.000000000000000,-80.000000000000000)
Metadata:
  AREA_OR_POINT=Area
  TIFFTAG_SOFTWARE=GRASS GIS 7.8.5 with GDAL 3.2.0
Image Structure Metadata:
  COMPRESSION=LZW
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  (   10243.086,   90778.184) (  8d 0'44.27"W, 40d29' 8.70"N)
Lower Left  (   10243.086,   54378.184) (  8d 0'46.37"W, 40d 9'28.60"N)
Upper Right (   54963.086,   90778.184) (  7d29' 5.53"W, 40d29' 2.39"N)
Lower Right (   54963.086,   54378.184) (  7d29'16.79"W, 40d 9'22.35"N)
Center      (   32603.086,   72578.184) (  7d44'58.23"W, 40d19'16.60"N)
Band 1 Block=559x3 Type=Float32, ColorInterp=Gray
  NoData Value=nan
@rouault
Copy link
Contributor

@rouault rouault commented Jan 2, 2021

slope_qgis_grass.tif has lost the information on the ETRS89 datum. I suspect GRASS must store the PROJ.4 string (which doesn't contain the ETRS89 datum information) and use it to set the CRS information on the final TIFF.

@gioman
Copy link
Contributor

@gioman gioman commented Jan 2, 2021

@rouault thanks for the pointer

@nyalldawson so the problem seems to be here

https://github.com/qgis/QGIS/blob/master/python/plugins/processing/algs/grass7/Grass7Algorithm.py#L1036
https://github.com/qgis/QGIS/blob/master/python/plugins/processing/algs/grass7/Grass7Algorithm.py#L1048

where we set the projection for the temp GRASS location/mapset using a PROJ string. We should use a WKT representation instead (and GRASS's g.proj allows it https://grass.osgeo.org/grass78/manuals/g.proj.html).

We can get the WKT representation needed with iface.mapCanvas().mapSettings().destinationCrs().toWkt() but the problem is that GRASS's g.proj wants it in a text file -without any quotes (and toWkt() returns it quoted)- rather than as a string. Not sure I'm able to create a patch to fix this.

I tried it by hard-coding the path to a file containing the WKT representation of the CRS of several test data in different CRSs and it worked as expected.

@nyalldawson nyalldawson reopened this Jan 4, 2021
nyalldawson added a commit to nyalldawson/QGIS that referenced this issue Jan 4, 2021
of proj strings wherever possible

Because proj strings are lossy

Fixes qgis#18596
nyalldawson added a commit that referenced this issue Jan 12, 2021
of proj strings wherever possible

Because proj strings are lossy

Fixes #18596
nyalldawson added a commit to nyalldawson/QGIS that referenced this issue Jan 12, 2021
of proj strings wherever possible

Because proj strings are lossy

Fixes qgis#18596

(cherry picked from commit b295bd5)
nyalldawson added a commit to nyalldawson/QGIS that referenced this issue Jan 12, 2021
of proj strings wherever possible

Because proj strings are lossy

Fixes qgis#18596

(cherry picked from commit b295bd5)
nyalldawson added a commit to nyalldawson/QGIS that referenced this issue Jan 14, 2021
of proj strings wherever possible

Because proj strings are lossy

Fixes qgis#18596

(cherry picked from commit b295bd5)
nyalldawson added a commit that referenced this issue Jan 15, 2021
of proj strings wherever possible

Because proj strings are lossy

Fixes #18596

(cherry picked from commit b295bd5)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

6 participants