<div dir="ltr">Hi all,<br><br>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):<br><br>$ time gdal_translate /vsis3/bucket/mosaic.vrt /tmp/out.tiff -projwin -9177335.364031402 5305341.259217514 -9174889.379126277 5302895.274312388 -outsize 256 256 -r nearest<br>Input file size is 52916, 61539<br>0...10...20...30...40...50...60...70...80...90...100 - done.<br><br>real    0m3.418s<br>user    0m0.234s<br>sys     0m0.297s<br><br>Takes about 3 seconds to produce a downsampled 256x256 subset. If I switch the re-sampling method to 

bilinear:<br><br>

$ time gdal_translate /vsis3/bucket/mosaic.vrt /tmp/out.tiff -projwin -9177335.364031402 5305341.259217514 -9174889.379126277 5302895.274312388 -outsize 256 256 -r bilinear
<br>Input file size is 52916, 61539<br>0...10...20...30...40...50...60...70...80...90...100 - done.<br><br>real    0m54.588s<br>user    0m13.563s<br>sys     0m3.438s<br><br>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.<br><br>If I turn GDAL debug statements on I can see that the first command uses the the pre-built COG overviews:<br><br>...<br>GTiff: Opened 1991x30351 overview.<br>GTiff: Opened 996x15176 overview.<br>GTiff: Opened 498x7588 overview.<br>...<br><br>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?<br><br>The COGs all have internal overviews and gdalbuildvrt is used to create the VRT file itself.<br><br>Any input or suggestions would be appreciated.<br><br>Thanks,<br><br>Angus</div>