OSGeo
Allow `gdalbuildvrt` to accept predefined pixel functions
Feature description
One use case of gdalbuildvrt is to mosaic overlapping rasters with the pixel value for overlapped pixels derived from pixel functions. For example, this is useful for flood maps, where you want the highest flood depth to take priority whenever there are overlapping rasters.
There are some predefined pixel functions available https://gdal.org/en/stable/drivers/raster/vrt.html#default-pixel-functions (including the max which I need), but currently, the only way to use them is to manipulate the created VRT manually.
It would be nice to have a CLI flag that can take predefined functions and add the pixel function in VRT.
Additional context
From my research, I couldn't find this functionality (create a mosaic raster but with max pixel value) in other gdal tools such as gdal_merge or gdaltindex. It would be nice to have this functionality in these tools as well.
@rouault A challenge I'm finding with this is a pixel function has no good way (that I can see) to determine which sources actually overlap a given pixel. We have the SkipNonContributingSources tag that prevents a source from participating if it doesn't intersect the window we're trying to read, but we still get zero values passed to the pixel function if a source partially intersects the window we're reading.
but we still get zero values passed to the pixel function if a source partially intersects the window we're reading.
we should probably initialize to the nodata value, but that would mean that all pixel functions should be aware of it (typically 0 is a good value for add)
@dbaston thanks for taking this on. It may also be a good time to revisit why SkipNonContributingSources is False by default. I think in most use cases we would like it to be True, No?
we should probably initialize to the nodata value
What if we don't have a NoData value? I was thinking of a non-standard NaN (this is how R handles NA, its version of NoData), but that only works if SourceTransferType is floating point. To handle all data types, wouldn't the pixel function need to be provided with a mask?
What if we don't have a NoData value?
I think we can just issue a warning. Providing the pixel functions with a mask seems too disruptive, and creating a VRT with multiple sources and no way to represent "no source" seems like it should be discouraged anyway.
@rouault I will make the built-in pixel functions NoData-aware, and add the propagateNoData argument (used for min and max pixel functions) to give some control over how NoData should be handled.