[gdal-dev] Reading a VRT file & overview usage

Angus Dickey angus at myheat.ca
Thu Oct 29 16:56:31 PDT 2020


Hi all,

I am using gdal_translate to read a VRT file made up of COGs stored in S3.
This works great when downsampling using nearest neighbour (GDAL 2.4.2):

$ time gdal_translate /vsis3/bucket/mosaic.vrt /tmp/out.tiff -projwin
-9177335.364031402 5305341.259217514 -9174889.379126277 5302895.274312388
-outsize 256 256 -r nearest
Input file size is 52916, 61539
0...10...20...30...40...50...60...70...80...90...100 - done.

real    0m3.418s
user    0m0.234s
sys     0m0.297s

Takes about 3 seconds to produce a downsampled 256x256 subset. If I switch
the re-sampling method to bilinear:

$ time gdal_translate /vsis3/bucket/mosaic.vrt /tmp/out.tiff -projwin
-9177335.364031402 5305341.259217514 -9174889.379126277 5302895.274312388
-outsize 256 256 -r bilinear
Input file size is 52916, 61539
0...10...20...30...40...50...60...70...80...90...100 - done.

real    0m54.588s
user    0m13.563s
sys     0m3.438s

Takes about a minute. I would assume that any of the re-sampling methods
will take longer than nearest, but 51 seconds longer? That can't just be
the extra processing.

If I turn GDAL debug statements on I can see that the first command uses
the the pre-built COG overviews:

...
GTiff: Opened 1991x30351 overview.
GTiff: Opened 996x15176 overview.
GTiff: Opened 498x7588 overview.
...

But the second command ignores the overviews and downloads the full
resolution imagery leading to very long download times. Is it expected
behaviour that all re-sampling methods except 'nearest neighbour' need to
request the full resolution data? Can't they apply the selected re-sampling
method to the overviews? Is it something to do with the way I created my
VRT file?

The COGs all have internal overviews and gdalbuildvrt is used to create the
VRT file itself.

Any input or suggestions would be appreciated.

Thanks,

Angus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20201029/d507c2d0/attachment.html>


More information about the gdal-dev mailing list