Incorrect handling of ASCII Gridded XYZ Data with QGIS >= 3.26

[christro]

What is the bug or the crash?

I am dealing with DEM data of the Bavarian Survey which can be downloaded from here: https://geoportal.bayern.de/bayernatlas/?lang=de&topic=ba&catalogNodes=11&bgLayer=atkis&E=677637.02&N=5437310.31&zoom=3&layers=KML%7C%7Chttp:%2F%2Fwww.geodaten.bayern.de%2Fopendata%2FDGM50_UTM32%2FOpenData_DGM50_25832.kml%7C%7Ctrue

The data are normal ASCII Gridded XYZ Data which are displayed in QGIS 3.22 without any problems:

If I load the same data to QGIS 3.26 / 3.28 a non existing alpha channel is added

And if I check the data with gdalinfo, which is installed by QGIS 3.26/3.28 I get the following output:

/Applications/QGIS.app/Contents/MacOS/bin/gdalinfo -stats sandbox/asciii_grid/72_528t50dgm.txt

Driver: XYZ/ASCII Gridded XYZ
Files: sandbox/asciii_grid/72_528t50dgm.txt
       sandbox/asciii_grid/72_528t50dgm.txt.aux.xml
Size is 200, 200
Origin = (719975.000000000000000,5279975.000000000000000)
Pixel Size = (50.000000000000000,50.000000000000000)
Corner Coordinates:
Upper Left  (  719975.000, 5279975.000) 
Lower Left  (  719975.000, 5289975.000) 
Upper Right (  729975.000, 5279975.000) 
Lower Right (  729975.000, 5289975.000) 
Center      (  724975.000, 5284975.000) 
Band 1 Block=200x1 Type=Float32, ColorInterp=Undefined
  Min=738.430 Max=1876.590 
  Minimum=738.430, Maximum=1876.590, Mean=1166.009, StdDev=265.067
  Metadata:
    STATISTICS_MAXIMUM=1876.5899658203
    STATISTICS_MEAN=1166.0089087982
    STATISTICS_MINIMUM=738.42999267578
    STATISTICS_STDDEV=265.06726267767
    STATISTICS_VALID_PERCENT=100

So also gdalinfo shows only one band and no alpha channel. In my opinion this is a very inconsistent way to handle the same data set. I detected this only, because for QGIS >= 3.26 the QGIS2threejs plugin doesn't handle the XYZ ascii grid as valid DEM data.

The test data can be downloaded directly from here: https://www.geodaten.bayern.de/opendata/DGM50_UTM32/72_528t50dgm.zip

Steps to reproduce the issue

Add the data as raster source to QGIS 3.26 / 3.28

The test data can be downloaded directly from here: https://www.geodaten.bayern.de/opendata/DGM50_UTM32/72_528t50dgm.zip

Versions

QGIS version | 3.26.3-Buenos Aires
QGIS version | 3.28.0-Firenze

Supported QGIS version

• I'm running a supported QGIS version according to the roadmap.

New profile

• I tried with a new QGIS profile

Additional context

No response

[nyalldawson]

@rouault this is coming from https://github.com/qgis/QGIS/blob/master/src/core/providers/gdal/qgsgdalprovider.cpp#L3544 -- we're explicitly setting the alpha band here

I think the issue is that this logic should only be getting applied when there's rotation present, not when there's a vertical flip present (as is the case in this raster). But I'm not confident on that, and would love your thoughts...

[rouault]

I think the issue is that this logic should only be getting applied when there's rotation present, not when there's a vertical flip present (as is the case in this raster). But I'm not confident on that, and would love your thoughts...

yes, the alpha band should not be addef in the case where

  // South-up oriented raster without any rotation, GCP or RPC doesn't need alpha band
 ( hasGeoTransform
         && ( mGeoTransform[1] > 0.0
              && mGeoTransform[2] == 0.0
              && mGeoTransform[4] == 0.0
              && mGeoTransform[5] > 0.0 ) )
       && GDALGetGCPCount( mGdalBaseDataset ) == 0
       && !GDALGetMetadata( mGdalBaseDataset, "RPC" ) )