[Gdal-dev] Re: SoC project status

[Adam Nowacki]

Frank Warmerdam wrote:
> As mentioned earlier, I'd like to see the design living in the GDAL Trac
> Wiki.  Design review of the driver ought to take place on gdal-dev.

http://trac.osgeo.org/gdal/wiki/SoCWMSDriver

but I don't really like the way editing works there, It's all same 
looking text.
Can we get C++ syntax coloring ? 
http://trac.osgeo.org/gdal/wiki/TracSyntaxColoring

> 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.

Another thing is serial nature of block based IO. Only one image could 
be downloaded at same time (unless some clever prefetching is 
implemented). A bigger request to RasterIO can be serviced using 
parallel http connections and/or pipelining making it several times faster.

> As mentioned earlier, I don't think the background thread/curl/adviseread
> stuff should be done in the first pass.  So please plan initially
> on a single threaded approach with that as an optional development
> once the basics are all working.

Background thread / AdviseRead, I can forget it for a while ... but 
CURL, do you mean that I should not use CURL in the driver ? WCS driver 
already does so why couldn't WMS ?

> Lastly, I try not to use std::string in GDAL, but instead to use CPLString
> which is derived from std::string.

I know, it's just a habit of using std::string. I can mass rename it to 
CPLString.

> I quite excited about supporting so many different datasources - it hadn't
> really sunk in with me that you were going to do more than just WMS!

They all are fairly similar. The only real differences are the URLs 
hence the short mini-drivers.