[Gdal-dev] WCS Client Driver

[Howard Butler]

+1 from me as well.

At 01:20 PM 10/5/2006, Daniel Morissette wrote:
>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/
>_______________________________________________
>Gdal-dev mailing list
>Gdal-dev at lists.maptools.org
>http://lists.maptools.org/mailman/listinfo/gdal-dev