[gdal-dev] Support for Terrain-RGB

[Javier Jimenez Shaw]

Hi

Independently of the convenience of making a new driver or adding it to
gdaldem, I am curious about the initial question:

Perhaps the same thing could also be achieved using the
raster calculator (gdal_calc), but that seems far from trivial for most
users.

Is it easy to use a formula to read it? Via a virtual file? Or the new CLI
commands?

Thanks.

On Thu, 8 Jan 2026 at 11:05, Lars Ahlzen via gdal-dev <
gdal-dev at lists.osgeo.org> wrote:

> 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
>
> _______________________________________________
> 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/7eba30a3/attachment.htm>