Re: [gdal-dev] Overriding IRasterIO in class derived from GDALRasterBand

2009-08-12 Thread Frank Warmerdam
2009/8/9 Jorge Arévalo jorge.arev...@gmail.com: Then, my point could be, when creating the dataset (Open static method), perform a query to get all the blocks that cover the extent of the raster (the extent is in RASTER_COLUMNS table) and store them in any place (A new class attribute?, flush

Re: [gdal-dev] Overriding IRasterIO in class derived from GDALRasterBand

2009-08-12 Thread Mateusz Loskot
Frank Warmerdam wrote: 2009/8/9 Jorge Arévalo jorge.arev...@gmail.com: Then, my point could be, when creating the dataset (Open static method), perform a query to get all the blocks that cover the extent of the raster (the extent is in RASTER_COLUMNS table) and store them in any place (A new

Re: [gdal-dev] Overriding IRasterIO in class derived from GDALRasterBand

2009-08-12 Thread Jorge Arévalo
Hello, 2009/8/12 Mateusz Loskot mate...@loskot.net: Frank Warmerdam wrote: 2009/8/9 Jorge Arévalo jorge.arev...@gmail.com: Then, my point could be, when creating the dataset (Open static method), perform a query to get all the blocks that cover the extent of the raster (the extent is in

Re: [gdal-dev] Overriding IRasterIO in class derived from GDALRasterBand

2009-08-12 Thread Mateusz Loskot
Jorge Arévalo wrote: Hello, 2009/8/12 Mateusz Loskot mate...@loskot.net: Frank Warmerdam wrote: 2009/8/9 Jorge Arévalo jorge.arev...@gmail.com: Then, my point could be, when creating the dataset (Open static method), perform a query to get all the blocks that cover the extent of the

Re: [gdal-dev] Overriding IRasterIO in class derived from GDALRasterBand

2009-08-12 Thread Tamas Szekeres
2009/8/12 Jorge Arévalo jorge.arev...@gmail.com I'm afraid I have not quite followed the discussion of the IRasterIO implementation, but I find the above statement quite alarming. It is imperative that we *not* end up reading back all blocks if only a few are requested. Imagine a 100GB

Re: [gdal-dev] Overriding IRasterIO in class derived from GDALRasterBand

2009-08-12 Thread Jorge Arévalo
Hello, 2009/8/12 Tamas Szekeres szeker...@gmail.com: 2009/8/12 Jorge Arévalo jorge.arev...@gmail.com I'm afraid I have not quite followed the discussion of the IRasterIO implementation, but I find the above statement quite alarming. It is imperative that we *not* end up reading back all

Re: [gdal-dev] Overriding IRasterIO in class derived from GDALRasterBand

2009-08-09 Thread Jorge Arévalo
2009/8/7 Even Rouault even.roua...@mines-paris.org: - Original Message - From: Jorge Arévalo jorge.arev...@gmail.com To: Tamas Szekeres szeker...@gmail.com Cc: gdal-dev gdal-dev@lists.osgeo.org Sent: Friday, August 07, 2009 7:43 PM Subject: Re: [gdal-dev] Overriding IRasterIO

Re: [gdal-dev] Overriding IRasterIO in class derived from GDALRasterBand

2009-08-09 Thread Jorge Arévalo
Hello Tamas, 2009/8/8 Tamas Szekeres szeker...@gmail.com: Hi Jorge, What I have in my mind is something like the DirectRasterIO implementation in  WCSDataset / WCSRasterBand (see wcsdataset.cpp). It appears that this driver is suffering from the same issue, and intend to minimize the

Re: [gdal-dev] Overriding IRasterIO in class derived from GDALRasterBand

2009-08-08 Thread Jorge Arévalo
Hello, 2009/8/7 Tamas Szekeres szeker...@gmail.com: Just thinking out loadly; Wouldn't it be easier to implement that cache at the driver level, just by composing the raster in a temp image buffer and feed that image in the subsequent IReadBlock calls? I think we should also think about the

Re: [gdal-dev] Overriding IRasterIO in class derived from GDALRasterBand

2009-08-08 Thread Tamas Szekeres
Hi Jorge, What I have in my mind is something like the DirectRasterIO implementation in WCSDataset / WCSRasterBand (see wcsdataset.cpp). It appears that this driver is suffering from the same issue, and intend to minimize the roundtrips to the server as much as possible. It looks like this

[gdal-dev] Overriding IRasterIO in class derived from GDALRasterBand

2009-08-07 Thread Jorge Arévalo
Hello, Context: GDAL WKT Raster driver In my class derived from GDALRasterBand, I've overrided the methods: - IReadBlock: Fetch a block from database - IRasterIO: Should fetch several blocks, that cover an area, and add them to papoBlocks (cache). The idea is to avoid rounds in the server

Re: [gdal-dev] Overriding IRasterIO in class derived from GDALRasterBand

2009-08-07 Thread Tamas Szekeres
Jorge, Did you call DropLock() right after copying the data on the newly allocated block? This assertion shows the raster block have remained in locked state. It's quite annoying if you find long executing times somewhere. Did you know how much time required to fetch the data and place that into

Re: [gdal-dev] Overriding IRasterIO in class derived from GDALRasterBand

2009-08-07 Thread Jorge Arévalo
2009/8/7 Tamas Szekeres szeker...@gmail.com: Jorge, Did you call DropLock() right after copying the data on the newly allocated block? This assertion shows the raster block have remained in locked state. OK, I commented this part during tests, -1 for me. The assertion disappeared. Many

Re: [gdal-dev] Overriding IRasterIO in class derived from GDALRasterBand

2009-08-07 Thread Tamas Szekeres
2009/8/7 Jorge Arévalo jorge.arev...@gmail.com One issue with this concept would be related to the limited memory size of the particular machine, it may be more reasonable to copy the retrieved blocks directly onto the output buffer if possible. In this case you cannot much rely on the

Re: [gdal-dev] Overriding IRasterIO in class derived from GDALRasterBand

2009-08-07 Thread Tamas Szekeres
Just thinking out loadly; Wouldn't it be easier to implement that cache at the driver level, just by composing the raster in a temp image buffer and feed that image in the subsequent IReadBlock calls? I think we should also think about the non regular and overlapping blocks which should also be