Fails to open geotiff due to unsupported format `GrayFloat32`

[dmkaplan2000]

To start a map, I downloaded some digital terrain model data for France as a geotiff from this website. When I go to open this data in OOM as a template, it fails with the following error:

Cannot open template
/home/dmk/Downloads/LHD_FXX_0757_6276_MNT_O_0M50_LAMB93_IGN69.tif:
Unsupported raster data: GrayFloat32
Unable to read image data

I imagine this is because the tif is a 1D grayscale image. First, is this expected behavior? Second, is there a way to transform this file to get it into OOM? I can contour it as linestrings or polygons in other software, but it would be nice to be able to import the original image for all the finescale features.

[dl3sdo]

Hello @dmkaplan2000,
as expected, I got the same error message. I can't tell whether it's an issue with the (older) GDAL version used by Mapper or something else.
I can open that .tif in QGIS and create a hillshading image (base map is the .osm for that area):

[dg0yt]

This is multi-level game: Mapper (or QGIS) -> GDAL -> GeoTIFF -> TIFF -> Compression.

There were number of improvements in GDAL and GeoTIFF. These improvements have not yet landed in binary releases of Mapper for Windows, macOS or Android. On Linux, our binaries (via OBS) use the distros' GDAL and GeoTiff. But it doesn't really matter. I tested a downloaded data file with a local build with Qt 5.15 and latest version of other dependencies. This doesn't make a difference.

TIFF isn't just for images but also generic raster data, like elevation. Mapper only deals with images. Data needs some processing for visualization. This is where we need to point at tools like QGIS at the moment.

[dg0yt]

For example, a test file from that source for Lyon is reported by gdalinfo with

Band 1 Block=2000x1 Type=Float32, ColorInterp=Gray
  Min=162.107 Max=298.862 
  Minimum=162.107, Maximum=298.862, Mean=250.491, StdDev=40.795
  NoData Value=-9999
  Metadata:
    STATISTICS_APPROXIMATE=YES
    STATISTICS_MAXIMUM=298.86157226562
    STATISTICS_MEAN=250.49052063237
    STATISTICS_MINIMUM=162.1067199707
    STATISTICS_STDDEV=40.794913868186
    STATISTICS_VALID_PERCENT=100

This is (Lugd'O'Night) elevation data.

[dmkaplan2000]

Hi, thanks for responding. I am using OOM on Ubuntu 24.04 with GDAL 3.8.4 (released 2024/02/08). I have successfully loaded the same files in R (using the stars package) and in QGIS, both of which depend on GDAL for reading and writing tifs, so it seems the GDAL version is enough to read this file. Is it not possible that OOM just doesn't understand how to treat the color scale/data type "GrayFloat32"? It would seem from the output of gdalinfo that the file does specify visualization of the data as grayscale, but perhaps OOM just isn't aware of this color scale?

I was able to generate contour lines and polygons in R and I can import those. The hillshade image from QGIS looks nice. I will try generating that.

[dmkaplan2000]

I may be way off base here, but looking at the OOM source code, it seems the function GdalImageReader::readRasterInfo is where the error originates because it fails to recognize the format (I don't do a lot of C++, so I may be lost here). There, if I understand correctly, it only looks for bands of type GDT_Byte, never of type GDT_Float32, which is presumably what GDAL is returning for these images. Could this be the source of the problem? Would it be possible to modify this function so that it recognizes and processes GDT_Float32 data, perhaps converting from GDT_Float32 to GDT_Byte using the GDALRasterBand::RasterIO function?

This is as far as my very limited C++/GDAL knowledge will take me. Hope this is helpful...

[dg0yt]

Would it be possible to modify this function so that it recognizes and processes GDT_Float32 data, perhaps converting from GDT_Float32 to GDT_Byte using the GDALRasterBand::RasterIO function?

This wouldn't help here. That's the point of my previous comment: Correctly reading "167.23 meters above sea level" doesn't give you the output you want in an orienteering map. The data needs to go through algorithms:

• for contours (vector output): GDALContourGenerate().
• for hillshading (raster output): GDALDEMProcessing().

[dmkaplan2000]

Would it be possible to modify this function so that it recognizes and processes GDT_Float32 data, perhaps converting from GDT_Float32 to GDT_Byte using the GDALRasterBand::RasterIO function?

This wouldn't help here. That's the point of my previous comment: Correctly reading "167.23 meters above sea level" doesn't give you the output you want in an orienteering map. The data needs to go through algorithms:

* for contours (vector output): [GDALContourGenerate()](https://gdal.org/en/stable/api/gdal_alg.html#_CPPv419GDALContourGenerate15GDALRasterBandHddiPdidPvii16GDALProgressFuncPv).

* for hillshading (raster output): [GDALDEMProcessing()](https://gdal.org/en/stable/api/gdal_utils.html#_CPPv417GDALDEMProcessingPKc12GDALDatasetHPKcPKcPK24GDALDEMProcessingOptionsPi).

I see what you are saying. I was assuming that GDALRasterBand::RasterIO would do the simplest translation of linearly scaling the values between the min and the max to the range 0 to 255, but reading the documentation a bit more carefully I see this is not the case. Perhaps the nearest short term solution would be to just adjust the error message so that it suggests the user run the data through a contouring or hillshading algorithm using QGIS or GDAL. Or you could just do the simple linear translation I mention (the min and max seem to be in the output of gdalinfo, so I suppose this is accessible with the GDAL appi), perhaps with a popup about the translation? This is undoubtedly what QGIS or R do by default when visualizing this data.

In any case, thanks for the help. I will look into hillshading myself.

[jjojala]

Alternatively you can use gdal command line tools to create countours or hillshade image, e.g:

This makes you georeferenced hillshade image, that can be opened as a template in OOM:

gdaldem hillshade tmp\dem_dense.tif field\Hillshade.tif -multidirectional -co compress=JPEG

This makes you GeoPackage (vector data) with 0,5m contour interval (tagged with "elev"). This can be also opened as a template in OOM and you can further import template to the map as well (i.e. contours will become objects on the map):

gdal_contour -i 0.5 -a "elev" tmp\dem_dense.tif tmp\contours05_dense.gpkg

I guess, these are the tricks you can alternatively do with QGIS as well if you prefer GUI for the job. In both cases DTM is only the source for some data products you actually want to use in mapping. OOM does not (at least currently) do these for you automatically. It's completely another discussion whether it should (maybe, but on the other hand, creating the DTM from lidar is I guess the most demanding part and it depends heavily on the lidar data itself and the terrain features - i.e. no necessarily generic way to do it, and with dense lidar data and large areas, it may also take hours to complete on average computer).

[jjojala]

Btw, with gdaldem tri once can create "terrain roughness index" (TRI) file (also tiff). I'am not completely sure whether it is usefull in mapping at all, but I did one, and it used float32 as a data format. So, I run it through:

gdal_translate -scale 0 0.4 -ot Byte tmp\tri-data.tif field\Tri.tif -co compress=JPEG

, and managed to get tiff-image that could be opened in OOM as an image. Note that "scale" parameters depends on your data (min/max values).

[dmkaplan2000]

Thanks, this is very helpful! I am kind of an R guy, so I mention that the stars package has an st_contour function (that is presumably a wrapper around GDAL) and there is a package called hillshader that will do hillshading.