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