[gdal-dev] Reworking the rasdaman driver

[Even Rouault]

Le mardi 12 février 2013 18:11:18, Fabian Schindler a écrit :
> Dear devs,
> 
> I've been tasked to improve or rewrite the current rasdaman driver
> implementation as it currently suffers a number of drawbacks:
> 
>   * it is quite slow (compared to other drivers and other rasdaman
>     connection techiques)
>   * it does not support creation of new rasters within the database
>   * it does not support write access to existing rasters within the
> database
> 
> I think the bad performance of the current implementation is due to the
> use of the `IReadBlock` function of the `RasdamanRasterBand`, as for
> every block that is read, a connection/transaction to the database is
> created and the block is transmitted.

Fabian,

That's certainly a reason that can account for the slowness.

> My assumption here is that reading
> the raster as a whole (or parts thereof) via `IRasterIO` (probably on
> the Dataset itself and not on the RasterBand) 

FYI, last time I checked, QGIS only uses RasterIO on the band object.

Lately, I've implemented a heuristics ( see 
http://trac.osgeo.org/gdal/changeset/25595 ) in the ECW driver that detect 
successive calls to ECWRasterBand::IRasterIO() with the same parameters but on 
bands 1, 2, ... N, and when this pattern is detected, it uses internally a 
dataset RasterIO() and cache the multiband buffer to server it to the 
individual band when they request it. But this is something very advanced that 
you probably don't need to look at in a first step. It is anyway only beneficial 
if rasdaman multiband rasters are pixel interleaved. If there are band 
interleaved, such trick is totally useless (and probably slightly counter 
productive)

> would improve the
> performance as the number of required connections and synchronization is
> reduced.
> As far as I can tell, that is the approach with the PostGISRaster driver.
> 
> What are your opinions to that matter? What benefits would I miss if I
> neglect block-based IO?

If you implement an efficient IRasterIO(), you *must* still implement 
IReadBlock() however (pure virtual method of GDALRasterBand). Or redirect it 
onto your IRasterIO() implementation, but that can be dangerous if your 
IRasterIO() implementation sometimes fallback on the generic one, that in turn 
will call IReadBlock().

Best regards,

Even