[Gdal-dev] WCS Client Driver

[Frank Warmerdam]

Daniel Morissette wrote:
> See question below...
> 
> Frank Warmerdam wrote:
>>
>> Because the of diversity of situations several read strategies will be
>> supported.
>>
>> 1) Block oriented with caching.  All requests to the remote server will
>> made based on the block size, and the blocks will be cached normally in
>> the GDAL memory block cache.  The default block size should be 
>> substantial,
>> perhaps 2MB blocks the width of the image.
>>
>> 2) 1:1 RasterIO() to GetCoverage. Each RasterIO() request will result 
>> in a
>> remote GetCoverage request at the resolution and for the exact region
>> requested.  Because of the irregular nature of requests, caching is
>> impractical.
>>
>> 3) Hybrid.  Block oriented with caching will be used for smallish 
>> requests,
>> while very large RasterIO() requests will be done as an immediate call 
>> but
>> expanded to block boundaries and the result pushed into the block 
>> cache.  The
>> benefit is that several blocks may be handled in a single request.
>>
>> The default operation will be to use the Hybrid mode.  Specific 
>> strategies
>> and block sizes can be forced via the service description file.
>>
> 
> If I'm not mistaken, none of these approach will allow caching that can 
> benefit stateless applications such as MapServer. i.e. if I use the 
> GDAL-WCS driver to access a remote WCS with MapServer, since each 
> request launches a new process then I won't get any caching, right?
> 
> While it is true that most requests to MapServer apps use different 
> BBOXes, it is very common to have an initial view that is always the 
> same or to have a set of predefined views and these predefined views may 
> account for a large portion of all hits to a server, so caching can be 
> beneficial in that case.
> 
> Would it be possible to have another method, possibly an extension of 
> the hybrid method, but that caches the images on disk. This way, image 
> blocks that are used frequently by apps such as MapServer would already 
> be on disk.
> 
> The implementation could be as simple as using the WCS request data (GET 
> URL) to forge the filename of the file in the cache. Then before issuing 
> a request you check if you already have the file on disk. This is how 
> the WFS client code does caching in MapServer.

Daniel,

Yes, it is true that local caching could be done as you describe.  I think
it is worth keeping in mind as an additional strategy though I must say I'm
not entirely keen on having to manage a cache on disk.

For stateful applications (including MapServer in FastCGI mode if we
could do some stuff to defer closing raster files) use of the "block oriented
with caching" strategy effectively accomplishing something similar in memory.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org