[gdal-dev] Support for Terrain-RGB

[Frédéric Trastour]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20260108/bf5c3d7e/attachment-0001.htm>