[gdal-dev] Support for Terrain-RGB

Thu Jan 8 12:51:16 PST 2026

>  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 ?

Totally agree, drop "terrain" and call it "gdal raster encode-rgb" or
something like that. There's nothing especially terrain (or topography)
about this afaics, and utility seems like the right approach rather than
creating a format variant.

Or is it perhaps a special case of offset/scale compression, like gdal
raster scale but with band splitting  and params rather than range?

Cheers, Mike

On Fri, Jan 9, 2026 at 1:19 AM Frédéric Trastour via gdal-dev <
gdal-dev at lists.osgeo.org> wrote:

> Hi,
> in the case of the driver solution, it could be used with gdal2tiles which
> is probably the next step of a RGB Terrain conversion.
> Regards,
> Fred.
>
> Le jeu. 8 janv. 2026 à 14:56, Even Rouault via gdal-dev <
> gdal-dev at lists.osgeo.org> a écrit :
>
>> 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.
>>
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>

-- 
Michael Sumner
Ordinary Member,  Streets People Love Hobart Association
Research Software Engineer
Australian Antarctic Division
Hobart, Australia
0438489030
e-mail: mdsumner at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20260109/4938d287/attachment-0001.htm>