Even, Does the shared attribute of a VRT sourceFilename element not affect caching at all? Is the cache avoided so that potentially stale data isn't propagated, or for other reasons?
On Fri, Apr 19, 2024 at 9:09 AM Even Rouault <even.roua...@spatialys.com> wrote: > Sean, > > Within a given GDALDataset opened on a VRT, if the VRT references several > times the same source, only one GDALDataset will be opened for it, so you > may benefit from the block cache mechanism (if it is triggered. > VRTSource::IRasterIO() calls IRasterIO() on the source band, which doesn't > necessarily always trigger block-based reading). But if you open another > VRT (or the same one), it will not share the same GDALDataset for sources > that may be common with the first one, so no re-use of existing block > cache. For network sources, the I/O cache at the /vsicurl/ level works > however on filenames, not VSIFILE* instances, so you will save network reads > > Even > Le 19/04/2024 à 16:48, Sean Gillies via gdal-dev a écrit : > > Happy Friday, folks! > > Are the source rasters of a VRT added to the block cache such that > different VRTs using the same source can avoid reads from disk or the > network? Or is it intended that the VSI cache covers this need instead? > > Thanks, > > -- Sean Gillies
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
