[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