[Gdal-dev] WCS Client Driver

[Daniel Morissette]

Sounds good. +1 from me.

Daniel


Frank Warmerdam wrote:
> 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,


-- 
Daniel Morissette
http://www.mapgears.com/