Transforming using ntv2 nadgrids is behaving different between GDAL 2.3.1 and GDAL 3.4.2

Question

I am working on upgrading to a newer version of GDAL and have an issue transforming coordinates using nadgrids (the beta2007.gsb ntv2 file which can be downloaded here) using GDAL 3.4.2.

The issue is that if I specify a nadgrid using a PROJ.4 string when using the gdaltransform commandline executable, I get an error that the transformation fails. Similar issues occur if I try to transform using the updated python or c++ libraries. For example, I try the following:

gdaltransform --version
GDAL 3.4.2, released 2022/03/08

gdaltransform --debug ON -s_srs EPSG:3044 -t_srs "+proj=tmerc +lat_0=0 +lon_0=12 +k=1 +x_0=4500000 +ellps=bessel +nadgrids=C:\temp\BETA2007.gsb +units=m +no_defs"
Enter X Y [Z [T]] values separated by space, and press Return.
4547442.8444401 5290333.4162611
OGRCT: Invalid argument
transformation failed.

However, if I do the same command using gdaltransform in GDAL 2.3.1, I get a successful transformation:

gdaltransform --version
GDAL 2.3.1, released 2018/06/22

gdaltransform --debug ON -s_srs EPSG:3044 -t_srs "+proj=tmerc +lat_0=0 +lon_0=12 +k=1 +x_0=4500000 +ellps=bessel +nadgrids=C:\temp\BETA2007.gsb +units=m +no_defs"
OGRCT: PROJ >= 4.8.0 features enabled
OGRCT: Source: +proj=utm +zone=32 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs
OGRCT: Target: +proj=tmerc +lat_0=0 +lon_0=12 +k=1 +x_0=4500000 +y_0=0 +ellps=bessel +nadgrids=C:\\temp\\BETA2007.gsb +units=m +no_defs
OGRCT: Source: +proj=tmerc +lat_0=0 +lon_0=12 +k=1 +x_0=4500000 +y_0=0 +ellps=bessel +nadgrids=C:\\temp\\BETA2007.gsb +units=m +no_defs
OGRCT: Target: +proj=utm +zone=32 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs
4547442.8444401 5290333.4162611
8171986.89299032 5104179.28005939 -3.96016985177994e-05

I have tried various things to get the transformation with the nadgrid to work, including using a wkt string with the nadgrid included. I am able to convert the coordinates from EPSG 3044 to EPSG 5678, but the coordinates are way off from where they should be. My question: Is there a way to define this BETA2007.gsb nadgrid that works correctly using the gdal commandline utilities, the python function calls, or the c++ function calls so I can get these coordinates converted without any errors?

Answer 1

I got this issue figured out with help from the GDAL folks after posting a bug to the GDAL list here.

The issue was that my original coordinates (4547442.8444401 5290333.4162611) were not located inside the BETA2007.gsb grid's domain. The original coordinates were actually in the DHDN projection (EPSG 5678). With newer versions of PROJ that are used with more recent versions of GDAL, the transformation fails if you are located outside the NTv2 grid's domain. So adding the "@null" onto the list of nadgrids allows you to project outside the grid's domain. So the following change to the original question fixed the problem:

gdaltransform --version
GDAL 3.4.2, released 2022/03/08

gdaltransform --debug ON -s_srs EPSG:3044 -t_srs "+proj=tmerc +lat_0=0 +lon_0=12 +k=1 +x_0=4500000 +ellps=bessel +nadgrids=C:\temp\BETA2007.gsb,@null +units=m +no_defs"
Enter X Y [Z [T]] values separated by space, and press Return.
4547442.8444401 5290333.4162611
8276390.34855434 5132236.65966789 0

Note the ,@null added onto the list of nadgrids. Visit the bug report response for more detailed information.

Answer 2

You could try setting the PROJ_LIB variable to the location of the PROJ data files on your computer if you haven't already tried that. You also need to set the GDAL_DATA and GDAL_DRIVER_PATH environment variables. For example:

SET GDAL_DATA=c:\gdal\data
SET GDAL_DRIVER_PATH=c:\gdal\data\gdalplugins
SET PROJ_LIB=c:\gdal\data\proj

There's also a PROJ_DEBUG variable you could turn on to see what kind of output PROJ is giving when you're using the NTv2 grid:

SET PROJ_DEBUG=3