[Bug] GDAL VRT with Int8 data type fail to import

[ninsbl]

Describe the bug

r.in.gdal and r.external fail to import GDAL Virtual Rasters (VRT) with Int8 datatype. Int8 was relatively recently introduced to GDAL (3.7) and then made available in VRT datasets. While GRASS GIS reads Int8 data in GeoTiff format, it fails with that datatype in VRT format.

To reproduce

# Create a Int8 raster in GeoTiff
gdal_create -ot Int8 -of GTiff -outsize 24 24 -burn 1 -a_srs EPSG:25833 -a_ullr 0 24 24 0 ./test.tif
# Create a VRT from it
gdal_translate -of VRT ./test.tif ./test.vrt
# Import the GeoTiff (works)
r.in.gdal -o input=test.tif output=test.tif
# Try to import the VRT (fails)
r.in.gdal -o input=test.vrt output=test.vrt
r.external -o input=test.vrt output=test.vrt

The last two commands fail with:

ERROR 1: Invalid dataType = Int8
ERROR: Unable to open datasource <test.vrt>

Expected behavior

GRASS GIS should import VRT with Int8 data.

System description

• Ubuntu 22.04
• GRASS GIS version: 8.4
• GDAL 3.7

Additional context

GRASS GIS does not seem to be the only one here: https://community.safe.com/data-7/int8-gdal-vrt-raster-not-supported-by-fme-18505

[neteler]

I guess it is "easy" to fix by adding GDT_Int8 support here (possibly with a test for the minimum required GDAL version, i.e. 3.7):

https://github.com/OSGeo/grass/blob/4aa4abf43f69d23ecdea932f3e550b5479df428f/raster/r.external/link.c#L17

[nilason]

Is this solved by #4256?

[nilason]

#4256 is merged and backported to 8.4, @ninsbl can this be closed?

[ninsbl]

#4256 is merged and backported to 8.4, @ninsbl can this be closed?

Yes. Thanks for backporting @nilason

[nilason]

Greit!