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
