[gdal-dev] read a catalog is slower then directly the raster ?

Dmitry Baryshnikov polimax at mail.ru
Tue Jan 31 15:03:22 EST 2012

31.01.2012 19:20, Even Rouault пишет:
>> Hi, Even
>> I faced this problem before. I checked under debugger and saw that vrt
>> sources were not creating overviews. So, gdal was making long RasterIO
>> executions to the source raster, but not overviews. I provided a patch
>> which took the overviews from origin raster and wrapped them too. May be
>> this is not so elegant solution, but it works and speed up work with
>> wrapped rasters considerably.
>> I don't thik that qgis under GDB/DDD will give any additional
>> information (one will just see long RasterIO executions).
>> But I can still try to use GDB if you think this might help.
> Dmitry,
> I don't deny the problem you describe. And your solution sounds reasonable. But
> without more precise context from Andrea, I just wanted to be sure that it was
> the precise case that Andrea ran into. There might be other issues involved
> (like histogram or statistics computations that can take a long time, but
> admitedly, I wouldn't expect the VRT overhead to be significant) and displaying
> the stack can show which first GDAL API call is involved.
Hello Even,

We have tested as you said. Also we added some code to check execution 
time of GDALRasterIO. We used two rasters in QGIS. First 
ftp://ftp.remotesensing.org/pub/geotiff/samples/misc/tjpeg.tif have 
rotation and warpped in QGIS, second - without rotation 
http://gis-lab.info/data/samples/tjpeg-unroated.7z (the same raster with 
removed rotation)

For first raster there was such situation (just only for one raster block):
GDALRasterIO time (ms): 18874

For second raster:
GDALRasterIO time (ms): 2

If you need more test, don't hesitate to say.
My be, it worth thinking to apply my patch.

Best regards,

More information about the gdal-dev mailing list