Hi Even, On 05/01/2026 14:50, Even Rouault wrote:
I would rather see that as a standalone TerrainRGB raster driver, leveraging the PNG driver underneath.
That was my original thought as well. Then, after thinking about different use cases I thought adding a gdaldem mode would allow for a wider range of workflows.
That said, you probably have a better idea of what would work best for GDAL as a whole, so I can look in that direction.
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") )
I don't think there's any sort of indication of the encoding in the files themselves (please correct me if I'm wrong). I imagine the need to decode Terrain-RGB back into a single-band DEM would be rare anyway, so a write-only driver might be sufficient.
- Lars _______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
