> -------Original Message------- > From: Even Rouault <[email protected]> > To: [email protected] > Subject: Re: [gdal-dev] Reworking the rasdaman driver > Sent: Feb 12 '13 12:32 > > 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. >
I agree with that. The other thing is that, as far I know, rasdaman is database-agnostic, so without much knowledge about any specific database system, the driver will probably be limited to issue one statement per block what is probably another source of 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 That is cool. > 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 > _______________________________________________ > gdal-dev mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/gdal-dev _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
