[gdal-dev] read a catalog is slower then directly the raster
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.
> 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.
We have tested as you said. Also we added some code to check execution
time of GDALRasterIO. We used two rasters in QGIS. First
rotation and warpped in QGIS, second - without rotation
http://gis-lab.info/data/samples/tjpeg-unroated.7z (the same raster with
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.
More information about the gdal-dev