Hi Lars,
I would rather see that as a standalone TerrainRGB raster driver,
leveraging the PNG driver underneath.
For the read side, if one is desired (write-only drivers are possible),
is there a way in metadata or file naming of distinguishing a regular
RGB PNG file from a Terrain-RGB one? If not, the Identify() function
should rely on users providing a "TerrainRGB:" prefix or specifying
explicitly the driver in the GDALOpenInfo::papszAllowedDrivers member
(testable with poOpenInfo->IsSingleAllowedDriver("TerrainRGB") )
Even
Le 05/01/2026 à 15:15, Lars Ahlzen via gdal-dev a écrit :
Hi all,
For Open/WebGL-based client side map rendering libraries, like
MapLibre or Mapbox GL, Terrain-RGB [1] (original spec by MapBox I
believe) seems to be the elevation encoding of choice.
The encoding itself, meant for use with 8-bits per channel RGB raster
formats such as PNG tiles, is straightforward:
elevation (in meters) = -10000 + 0.1 * (R * 65536 + G * 256 + B)
As far as I know a separate tool is typically used for the encoding,
such as rio-rgbify [2] from Mapbox. There's an example writeup of such
workflow at [3]. Perhaps the same thing could also be achieved using
the raster calculator (gdal_calc), but that seems far from trivial for
most users.
It looks like it would be relatively easy to add native support for
this in GDAL, perhaps as another mode in gdaldem. Would it make sense
if I gave that a try?
- Lars
[1] https://blog.mapbox.com/global-elevation-data-6689f1d0ba65
[2] https://github.com/mapbox/rio-rgbify
[3] https://github.com/syncpoint/terrain-rgb/blob/master/README.md
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
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
