[Gdal-dev] Re: SoC project status

[Frank Warmerdam]

Adam Nowacki wrote:
>
> 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

Adam,

I'll look into the syntax coloring.  Could you file a ticket against
component "SAC" in the OSGeo trac instance about this?

   http://trac.osgeo.org/osgeo/

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

I'm not sure I understand.  When you talk about the "base image", do you
mean the highest resolution (biggest image) or the top of the overview
stack?  How does block oriented access make the fact that the full
resolution image is big any harder?

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

That's an interesting point.  I can see there would be a substantial
benefit to fetching a bunch of tiles in parallel needed for a given
request region.

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

I didn't mean not too use curl.  I meant to not attempt to do it
in a distinct thread or threads.  Absolutely, do use curl.

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