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 <[email protected]>:
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
[email protected]
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
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
