[Gdal-dev] WCS Client Driver
dmorissette at mapgears.com
Thu Oct 5 14:20:03 EDT 2006
Sounds good. +1 from me.
Frank Warmerdam wrote:
> Daniel Morissette wrote:
>> See question below...
>> Frank Warmerdam wrote:
>>> Because the of diversity of situations several read strategies will be
>>> 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
>>> 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
>>> 3) Hybrid. Block oriented with caching will be used for smallish
>>> 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
>>> 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.
> 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
> with caching" strategy effectively accomplishing something similar in
> Best regards,
More information about the Gdal-dev