[gdal-dev] Random Raster Driver

[Alex Hagen-Zanker]

Hi Even,

Random rasters are indeed fairly common functionality, and used for instance in dynamic simulations, synthetic landscape generation and some Monte Carlo type statistical approaches.

Having the random raster as a VRT does make sense to me, it would side-by-side with other generated raster types. I also agree that it would be preferred over having yet another raster format, especially if it is not-really-a-data-format.

I am not sure if I understand your suggestion correctly. Are you suggesting to change the behaviour or VRT DerivedRasterBand in general so that its IRasterIO would only work on block boundaries? That seems quite drastic to me. I think there would be a few more minor adaptations necessary for VRTDerivedRasterBand so that it can accept that there are zero source layers for the pixel function.

Looking at VRTDerivedRasterband I was surprised that it implements IRasterIO rather than IReadBlock. If you indeed meant to restrict IRasterIO to block boundaries in general, would it be a consideration to implement it as IReadBlock and use default behaviour for IRasterIO? From my understanding that would change the way the caching works, as it would cache the results of the pixel function rather than the input to the pixel function. It would also allow RasterIO to still be used as it currently is.

If you would leave it as IRasterIO, would the random values be cached at all? Or always just generated when requested?

Kind regards, Alex


________________________________
From: Even Rouault <even.rouault at spatialys.com>
Sent: 05 July 2025 13:44
To: Alex Hagen-Zanker <alexhighviz at hotmail.com>; gdal-dev at lists.osgeo.org <gdal-dev at lists.osgeo.org>
Subject: Re: [gdal-dev] Random Raster Driver


Alex,


I'm not super familiar myself with the usage of such random rasters, but it seems to be fairly common indeed in GIS software, and could likely make sense within GDAL too. I'm wondering if instead of having a new driver, the random distribution functions could not be exposed as VRT C++ built-in pixel functions (https://gdal.org/en/stable/drivers/raster/vrt.html#built-in-pixel-functions).  That would make it possible to benefit from all the rest of the VRT infrastructure like setting geospatial information, adding metadata, multiband support etc There would be a bit of tweak to do in the VRTDerivedRasterBand in that case to force it to always operate on block boundaries (instead of any arbitrary requested window), so that the per-block seed can be used, but that should mostly be a matter of a few lines to add in its IRasterIO() implementation.


Even


Le 04/07/2025 à 19:08, Alex Hagen-Zanker via gdal-dev a écrit :
Hi all,

I implemented a plugin raster format that produces raster of random values using the all the distributions that are offered by the standard library's random header. It is different from other random raster functionality in e.g. ArcGIS or QGIS because it does not store the data on file but generates blocks of data on-demand.

Now it is for my own use, but I'd be happy to polish it up if it can become part of GDAL.

There is documentation here:

https://github.com/ahhz/random-raster/blob/main/docs/random_raster_driver.md
[https://opengraph.githubassets.com/6043ab82cae0d7a681691a0536f0523cc36150ff5a466ad797d69782e59b5e8b/ahhz/random-raster]<https://github.com/ahhz/random-raster/blob/main/docs/random_raster_driver.md>
random-raster/docs/random_raster_driver.md at main · ahhz/random-raster<https://github.com/ahhz/random-raster/blob/main/docs/random_raster_driver.md>
Create GDALDatasets containing rasters of random values, that do not store the values on disk - ahhz/random-raster
github.com
Would this be of interest as a GDAL format?

Kind regards, Alex





_______________________________________________
gdal-dev mailing list
gdal-dev at lists.osgeo.org<mailto:gdal-dev at lists.osgeo.org>
https://lists.osgeo.org/mailman/listinfo/gdal-dev


--
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20250706/23947fe3/attachment.htm>