[gdal-dev] Slow speed in remote reading

Alexander Verbitsky habibutsu at gmail.com
Mon Nov 2 12:07:25 PST 2020


I have checked. Yes, in using S2 COG with images in tiff format gdal makes
5 requests for getting 100x100px images and speed significantly higher in
comparison with jp2. Unfortunately the size of tiff-file in this case is
twice higher than corresponding jp2.

On Mon, Nov 2, 2020 at 6:28 PM Patrick Young <
patrick.mckendree.young at gmail.com> wrote:

> You can check how a S2 COG compares at
>
> https://registry.opendata.aws/sentinel-2-l2a-cogs/
>
> You should hopefully see a lot less network requests when accessing a sub
> block directly.
>
> P
>
>
> On Mon, Nov 2, 2020 at 7:58 AM Alexander Verbitsky <habibutsu at gmail.com>
> wrote:
>
>> Hi All, I am trying to implement remote reading small blocks of images,
>> but find slow performance.
>>
>> For example i am trying to read 100x100 block from `sentinel-2` image,
>> with using following code:
>>
>> filename = (
>>     '/vsigs/gcp-public-data-sentinel-2/tiles/31/U/FS/'
>>     'S2A_MSIL1C_20201024T104121_N0209_R008_T31UFS_20201024T125115.SAFE/'
>>
>> 'GRANULE/L1C_T31UFS_A027890_20201024T104121/IMG_DATA/T31UFS_20201024T104121_B08.jp2'
>> )
>> ds = gdal.OpenEx(filename, gdal.OF_RASTER)
>> band = ds.GetRasterBand(1)
>> img = band.ReadAsArray(1000, 1000, 100, 100)
>>
>> In result I am getting more low performance in comparison if I just
>> download the whole image in memory and then read the necessary block. AS I
>> understand it happens due to a lot of small requests (is about 100)  that
>> are made during reading a small part of the image. Is it a fundamental
>> feature of JP2OpenJPEG and this format not suitable for doing things like
>> that? Should I take another format like GeoTiff and store my own data in
>> it? Thank, for your reply.
>>
>>
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20201102/3ca91d84/attachment.html>


More information about the gdal-dev mailing list