[GRASS-dev] GRASS 'Unable to load GDAL library' when processing linked maps

I get an error message when I try to run the following on a linked ‘GDAL-supported pseudo-GRASS raster map’:

r.external input=myraster.tif output=myraster

r.null map=myraster setnull=0
ERROR: Unable to load GDAL library

When I run the same on a GRASS raster map, however, no error is triggered:

r.in.gdal input=myraster.tif output=myraster

r.null map=myraster setnull=0
100%

Is this expected behaviour? If so, and drawing such errors is unavoidable, then I will cease to use linked maps in future. However, in the interest of limiting storage space requirements, I find r.external and v.external to be effective ways of managing existing data without the need for duplication, so if avoiding such errors is feasible, I suggest this would be a valuable feature to consider for future releases.

Hi Tyler,

And thanks for your feedback.

Your issue is likely related to the issue here:

https://github.com/OSGeo/grass/issues/1872

Given that this obviously has wider consequences I took the liberty to elevate priority of the issue as a blocker…

A workaround will be available in GRASS 7.8.7 (or GRASS 8.0). Will see if it is possible to solve this temporarily via packaging… But a proper fix is needed.

Cheers

Stefan

···

From: grass-dev grass-dev-bounces@lists.osgeo.org On Behalf Of Tyler D. Rudolph
Sent: fredag 29. oktober 2021 17:49
To: grass-dev@lists.osgeo.org
Subject: [GRASS-dev] GRASS ‘Unable to load GDAL library’ when processing linked maps

I get an error message when I try to run the following on a linked ‘GDAL-supported pseudo-GRASS raster map’:

r.external input=myraster.tif output=myraster

r.null map=myraster setnull=0

ERROR: Unable to load GDAL library

When I run the same on a GRASS raster map, however, no error is triggered:

r.in.gdal input=myraster.tif output=myraster

r.null map=myraster setnull=0

100%

Is this expected behaviour? If so, and drawing such errors is unavoidable, then I will cease to use linked maps in future. However, in the interest of limiting storage space requirements, I find r.external and v.external to be effective ways of managing existing data without the need for duplication, so if avoiding such errors is feasible, I suggest this would be a valuable feature to consider for future releases.