[gdal-dev] Support for Terrain-RGB

[Even Rouault]

Hum, if there are different underlying formats, then the situation is 
not all that clear to me.

Both options would be reasonable

- as a driver:

gdal raster convert dem.tif rgbterrain.png --of terrainrgb --co 
OFFSET=-10000 --co SCALE=0.1  [--co DRIVER=PNG]

- or a gdal CLI command:

gdal raster terrainrgb dem.tif rgbterrain.png --offset=-10000 
--scale=0.1 [--driver PNG]

Perhaps the latter is slightly preferable ?  I've some doubts about the 
naming of the command though. There is a risk that "terrainrgb" would 
make users believe it does what "gdal raster color-map --color-map" 
does, that is create an hypsometric rendering of a DEM.  "encode-as-rgb" 
maybe ?

Le 08/01/2026 à 11:05, Lars Ahlzen a écrit :
>
> Good points.
>
> Given these and other comments, it sounds to me like we should support 
> different RGB raster formats, as the storage format really is 
> independent from the encoding. Also, supporting Mapbox Terrain RGB, 
> Terrarium RGB, and custom encodings would be desirable. I believe 
> these are all variants of the same thing anyway, with a base (offset) 
> and a scale for each of the R, G and B channels.
>
> Even, you probably know GDAL internals quite well, what are your 
> thoughts? If we were to support arbitrary RGB raster formats, would an 
> implementation elsewhere (like gdaldem) be more suitable than a new 
> raster driver, or could a raster driver support different actual file 
> formats?
>
> If the latter, could the existing MBTiles driver be used for direct 
> DEM -> RGB tiles (.png/.webp/...) -> .mbtiles generation?
>
> - Lars
>
> On 06/01/2026 08:40, Andrey VI wrote:
>> Hi all.
>>
>> It would be great to have RGB DEM support in GDAL.
>> Some considerations.
>> 1. It makes sense to add support not only for Mapbox Terrain RGB, but 
>> also for Mapzen Terrarium RGB [1][2] encoding. Mapbox and Maplibre 
>> support both encodings, the latter also supports custom encoding 
>> [3][4]. Therefore, support for custom encoding will also be useful.
>> 2. I don't quite understand why only PNG format is being discussed 
>> here. It is possible to encode a DEM into any raster RGB image 
>> format. Moreover, PNG isn't the most optimal of them [5]. In my 
>> opinion, the WEBP format is preferable. For example, Maptiler uses it 
>> for Terrain RGB and Ocean RGB datasets [6].
>> 3. Ideally, the output should be not just an encoded image, but tiles 
>> ready for use in Mapbox/Maplibre/etc., including in the form of data 
>> sets (MBTiles, PMTiles).
>> [1] https://www.mapzen.com/blog/terrain-tile-service/
>> [2] 
>> https://github.com/tilezen/joerd/blob/master/docs/formats.md#terrarium
>> [3] 
>> https://docs.mapbox.com/style-spec/reference/sources/#raster-dem-encoding
>> [4] https://maplibre.org/maplibre-style-spec/sources/#encoding_1
>> [5] 
>> https://medium.com/@frederic.rodrigo/optimization-of-rgb-dem-tiles-for-dynamic-hill-shading-with-mapbox-gl-or-maplibre-gl-55bef8eb3d86
>> [6] https://www.maptiler.com/on-prem-datasets/dataset/terrain-rgb/ 
>> <https://www.maptiler.com/on-prem-datasets/dataset/terrain-rgb/#0.22/0/0>
>>
>>     Tuesday, January 6, 2026 0:46 AM +03:00 from Lars Ahlzen via
>>     gdal-dev <gdal-dev at lists.osgeo.org>:
>>     On 05/01/2026 19:47, rayg wrote:
>>     > Strange encoding, -10000 meters isn't deep enough for the Marianas
>>     > Trench. You could borrow another 10 km from the 1.6 million meters
>>     > still available on the positive side.
>>     >
>>     > Scaling by 0.1 also means a 10 cm vertical resolution., which is
>>     > useless for some use cases. The 24 bits per pixel could be much
>>     better
>>     > allocated.
>>
>>     I kind of agree with both points, but I guess the format is what
>>     it is.
>>
>>     I don't think it's supposed to be a general-purpose storage
>>     format. It's
>>     encoding just enough data to do good enough real-time
>>     visualization of
>>     elevation, like hillshading or hypsometric tints, client side.
>>
>>     Looks like at least rio-rgbify [1] allows setting a custom base value
>>     and interval. That might be something we want to emulate as well,
>>     perhaps as creation options (if a raster format driver) or
>>     command line
>>     options (if part of gdaldem).
>>
>>     - Lars
>>
>>     [1] https://github.com/mapbox/rio-rgbify
>>
>>     _______________________________________________
>>     gdal-dev mailing list
>>     gdal-dev at lists.osgeo.org
>>     https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>>
>> --
>> Andrey

-- 
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20260108/2994bf5f/attachment.htm>