GDAL-Caching philosophy?

[Petri J. Riipinen]

Hi Frank & folks,

>I think the existing GDAL caching should give you good performance.
>You might want to play with GDAL's maximum memory for caching.

I want to clarify this a bit:

Let's say that I have a TIFF-file with one rasterband of size 4000x4000 
with 256-color palette.

First I use RasterIO to read a block from (1000,1000)-(2000,2000), that is 
1000x1000 pixels.

What is left into the RasterIO cache after the operation, assuming that it 
fits inside the maximum cache size?

What if the display now shifts one pixel and I read a block 
(1001,1001)-(2001,2001) with rasterIO from the same rasterband, does GDAL 
use anything from the cache or does it read everything from file? I guess I 
mean that is this always equally heavy operation or is there some 
improvement, if the consequtive blocks overlap.

What is actually left in the cache after those two rasterIO-operations?

You know, I just calculated that one 4000x4000 pixel, RGB-image takes over 
62 megs of memory!!! So, there is no way that I can actually cache 4 of 
those (the worst case, when corners of four adjacent blocks are on the 
viewport) in my 128 megs of memory, so I definitely need to be handling the 
caching and screen updating in some pretty smart way if I want to do it 
like that.

I'm now also considering moving into vector images instead of raster 
images. I'm discussing with Finnish National Landsurvey agency for 
licensing a 1:250 000 scale complete Finnish map as vectors (ESRI 
Shape-format) and I have the option whether to rasterize a suitable set of 
vector layers or just use the vectors. It might be that I might get 
somewhat more agile and responsibe software if I use quadtrees and vector 
shapes, and also not having to worry about caching large image buffers into 
memory.

Say Frank (or anyone reading this!), you being a pro in GIS-stuff, if you 
would have to do a GPS+map-navigation system, would you use raster or 
vector format, assuming both cover the same area?

- Petri
<><><><><><><><>
Petri J. Riipinen
petri.riipinen at n...
<><><><><><><><>