[gdal-dev] Reworking the rasdaman driver

[Ivan Lucena]

>  -------Original Message-------
>  From: Even Rouault <even.rouault at mines-paris.org>
>  To: gdal-dev at lists.osgeo.org
>  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
>  gdal-dev at lists.osgeo.org
>  http://lists.osgeo.org/mailman/listinfo/gdal-dev