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

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

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

Author Name: Giovanni Manghi (@gioman)

• category_id was changed from 94 to Processing/Core

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

Author Name: Giovanni Manghi (@gioman)

see also #20098

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

Author Name: Giovanni Manghi (@gioman)

• regression was configured as 1

Author Name: Giovanni Manghi (@gioman)

• priority_id was changed from Severe/Regression to High

Author Name: Giovanni Manghi (@gioman)

• easy_fix was configured as 0

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

Author Name: Giovanni Manghi (@gioman)

• version was changed from 2.18.7 to 2.18.10

Author Name: Giovanni Manghi (@gioman)

• version was changed from 2.18.10 to 2.18.11

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

• duplicated was configured as v.clean and v.clean advanced tools return cleaned layers with CRSs other than the CRSs of the input layers #25391

Author Name: Paolo Cavallini (@pcav)

• assigned_to_id removed Victor Olaya

Author Name: Giovanni Manghi (@gioman)

• version was changed from 2.18.11 to 3.0.0

Author Name: Giovanni Manghi (@gioman)

• version was changed from 3.0.0 to 3.3(master)

Author Name: Alexandre Neto (@SrNetoChan)

• version was changed from 3.3(master) to 3.4.1

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.

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

@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...

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.

... 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).

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

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

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

• PROJ 6.3.2 release notes: https://github.com/OSGeo/PROJ/releases/tag/6.3.2
• Code differences: OSGeo/PROJ@6.3.1...6.3.2

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:

• https://trac.osgeo.org/grass/wiki/Release/7.8.3-News#Projectionsupport
  • GDAL/OGR import: check projection of input data (​PR:317)
• https://trac.osgeo.org/grass/wiki/Release/7.8.4-News#Projectionsupport
  • fix proj 6+ support for share/proj/epsg (​PR:183)
• https://trac.osgeo.org/grass/wiki/Release/7.8.5-News#Projectionsupport
  • libproj: fix crs modification with PROJ6+ (​PR:1007)
  • libproj: fix test for PJ_TYPE_BOUND_CRS (​PR:1013)

Maybe that's the reason?

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.

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

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.

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...

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

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.

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.

@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

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.

@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.