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 _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
