[Gdal-dev] Re: SoC project status

[Adam Nowacki]

Frank Warmerdam wrote:
>>> I think it would make sense to use distinct driver implementations for
>>> the tile based datasources (TMS, Worldwind, etc) and WMS.  For the WMS
>>> driver it makes sense to override IRasterIO() and fetch the exact
>>> requested region at the requested resolution.
>>> But for fixed tile based data sources, I think you should just implement
>>> the IReadBlock() interface and leave it up to the normal GDAL blocking
>>> mechanism to handle mosaicing, etc.
>>
>> For base image it may be fine as the alignment required is only block 
>> size, usually 256x256 to 512x512. However, if you add overviews the 
>> alignment requirement grows by 2^n where n is number of overviews. For 
>> example to have all overviews in global 15 meter / pixel Landsat 
>> tileset the data window would have to be 2`700`000 x 1`300`000 pixels 
>> starting at (-180, 90). That big image may be a problem for some 
>> poorly coded applications.
> 
> I'm not sure I understand.  When you talk about the "base image", do you
> mean the highest resolution (biggest image) or the top of the overview
> stack?  How does block oriented access make the fact that the full
> resolution image is big any harder?
> 

Base image - the highest resolution image.
The data window allows you to limit the amount of data visible to GDAL 
in cases where app you're trying to use the data in is unable to handle 
such big images. No overviews could be allowed with block access then, 
or each overview block would have to fetch 4 tiles.