Datum transformation using custom gsb grid for WMS Layer in QGIS Server does not work

[danceb]

Hello there,

we have a problem using datum transformations within QGIS Server 3.16 on Ubuntu 20.04 (Focal Fossa). Within a qgs project with layers of different projections (EPSG: 3397 and EPSG: 25832) there is no datum transformation applied on these layers.

There are others with the same issue (https://gis.stackexchange.com/questions/364744/datum-transformation-in-qgis-server-3-10) but there are no replies yet.

It works with an older QGIS Server 2.18 whe have running.
On the newer one everything is set up like described in this thread: https://www.mail-archive.com/qgis-user@lists.osgeo.org/msg35445.html. The corresponding NTv2gridTH.gsb file is placed in the proj folder /usr/share/proj, there is an entry for the transformation within the srs.db and the standard transformation is defined in the apache configs.
But unfortunately this does not work on the newer QGIS 3.16 anymore. The function was implemented here:

QGIS/src/core/qgsmaprenderer.cpp

Line 1300 in 28c0380

const char* envChar = getenv( "DEFAULT_DATUM_TRANSFORM" );

, but the file qgsmaprenderer.cpp is not part of QGIS 3 anymore.

The hope was, that the QGIS Server recognizes a standard transformation of a project file, which can be set in project settings within "project - settings - transformation" (https://www.mail-archive.com/qgis-user@lists.osgeo.org/msg44456.html), but this setting has not effect on the interpretation of the QGIS Server.

Does the problem corresponse to changes with the use of PROJ6 since QGIS 3.10? (Another issue but mentioned here: https://www.mail-archive.com/qgis-user@lists.osgeo.org/msg45441.html)

Two raster layers with different projections loaded via wms from the qgis server:

Here is a qgs-project with two included raster layers with the named projections to test this on an own qgis server:
https://cloud.jena.de/index.php/s/0YWh2ZXE3MEEfjR

I would appreciate any help. Thanks!

[roya0045]

I assume that importing the same layers directly in QGIS would have the same effect. If this is the case then yes, it is highly probable that the changes of Proj are the root cause. You could just reproject the layer ( in proj4) to a supported proj6 CRS or correct the georeferencing.

Otherwise if the problem is only with the server, this may come from QGIS.

[danceb]

Thanks for the response!
No, direct import in Desktop QGIS workes fine. If I import the second raster with a different projection, QGIS asks me for a datum transformation to apply on the layer, saves them into to project settings an the rasters match themeselves correctly. The problem only occurs, if I load the layers with different projections from the wms server into qgis and leave them with the given projection (in the hope that the datum is transformed and the layer is reproject by the wms server).
I can set the projection to the original one during the wms-layer import manually. But the goal is, that the qgis server does the transformation for me, so that the users don't have to do this manually.

[danceb]

Further detection and declaration: "usual" transformations are working. E.g. a datum transformation of a raster with epsg:31468 (gauss kruger zone 4) is loaded with 25832 in correct position. It doesn't work if a custom gsb grid placed in /usr/share/proj should be used.

[elpaso]

There is no bug really but you couldn't have possibly known how to fix the issue because the server didn't tell you anything.

After downloading and installing the required grid file https://cdn.proj.org/de_adv_BETA2007.tif in the "user" /YOUR_QGIS_SETTINGS_PATH_ON_SERVER/proj everything worked just fine for me.

[danceb]

Hey @elpaso, thank you for your response and clarifying! We want to use a different grid file (NTv2gridTH.gsb), but I think the procedure will be the same. Something is still not working on our system but I have to figure this out by my own. With your message I am knowing now, that qgis server 3 should handle this correctly and it seems to be a configuration problem now.
And thanks a lot for your pull in #43365 !
If there is no other comment on this, I think we can close this.