This was my mistake. I had set `GDAL_DISABLE_READDIR_ON_OPEN=EMPTY_DIR`, which was preventing GDAL from noticing the .vrt.ovr file I had generated.
So, the answer is that the .vrt.ovr is just a TIF file, and it can be generated via gdal_translate and additional overviews added to it via gdaladdo 👍 Thanks :) On Wed, 17 Jul 2024 at 19:59, Craig de Stigter < craig.destig...@koordinates.com> wrote: > Hi folks > > I have a VRT which is a mosaic of several thousand s3-stored COGs. Doing > any kind of low-res downsampling from this VRT causes very slow performance > and high memory usage because it causes requests to all the individual > source tiles. > > I'd like to add external overviews to the VRT via a `.vrt.ovr` file – and > it appears I can do this with gdaladdo. > > However, a naive call to gdaladdo seems to ignore the overviews on all the > source files, rendering the overviews by downloading every pixel from the > full-size sources. This is a nonstarter in this environment where the full > set of source tiles is enormous and remote. > > So, two questions: > 1. Is there a way to force gdaladdo to use the COG overviews from the > source VRT's source tiles? > 2. If not, are there any other ways to generate a `.vrt.ovr` file which > would use the source overviews? I have tried using gdal_translate to > produce a .tif of the right pixel size and then renaming it to `.vrt.ovr`, > but it doesn't seem to be used by GDAL – so I guess there's more to `ovr` > files than just TIF files with the right name! > > -- > Regards, > Craig > > Platform Engineer > Koordinates > > +64 21 256 9488 <+64%2021%20256%209488> / koordinates.com / @koordinates > <https://twitter.com/koordinates> > -- Regards, Craig Platform Engineer Koordinates +64 21 256 9488 <+64%2021%20256%209488> / koordinates.com / @koordinates <https://twitter.com/koordinates>
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
