[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,
Dmitry
More information about the gdal-dev
mailing list