Hi Tamas, 2009/8/14 Tamas Szekeres <[email protected]>: > Hi Jorge, > > I really appreciate your efforts to sort these issues out. I consider these > issues would be crucial especially when the requested block number is large > or when using non regular (and possibly overlapped) blocking where each > IReadBlock may result in fetching multiple raster rows. >
Yes this situation is under control. Raising an "under development" message, but under control, anyway. > However I consider we should start considering how to finalize the GSoc > project at a well defined stage, which we could safely be incorporated in > the gdal project tree as a new driver. It would be required to write up some > documentation or test scripts to make sure the existing code is working > correctly, then we should also submit the final evaluations within the Aug > 17-24 interval according to the gsoc timeline. By all means please calculate > the necessary efforts to implement this enhancement we have recently been > talking about, and if it cannot be fitted in the gsoc timeline then go ahead > finalizing the existing implementation by adding the driver documentation > and scripts. Ok. I'll dedicate these last 2 days to simply finalize the GSoC-related work. > > So as to implement these enhancements after finishing the gsoc efforts > you're happily welcomed in the gdal team to contribute with the remaining > parts to make this driver really compelling to use. Keep up the good work, > Sounds really well. Thanks. Best regards, Jorge > > Best regards, > > Tamas > > > > > 2009/8/14 Jorge Arévalo <[email protected]> >> >> Hello, >> >> I've asked several concepts related with RasterIO-related methods in >> Dataset and RasterBand. Thanks to your responses, I've a better >> understanding of the GDAL drivers' I/O method. But I've a couple of >> doubts I need to solve to finish the GSoC, although I'd like to >> continue developing the driver after it. >> >> Problem: In basic GDAL WKT Raster driver, each row of a raster table >> (one block, in regularly blocked rasters) means one server round. This >> is slow, and "sub-optimal". >> >> How to solve it?: IReadBlock executes an spatial query to get all the >> rows of a table that fits in a natural block, defined by nXOff, nYOff >> and the values fetched by GetBlockSize. In many raster formats, one >> natural block is a scanline, of size (nXRasterSize, 1). In WKT Raster >> format, if we have a regularly blocked raster, "natural" block size >> will be equal to RASTER_COLUMNS-defined block size, and the query will >> return one block. To avoid one spatial query for each block petition, >> we should "force" the driver to get all the blocks covering the area >> requested in a IRasterIO call. >> >> How to implement it? My approach is based on implementing >> WKTRasterDataset::IRasterIO method (overriding GDALDataset::IRasterIO >> method). This method executes a spatial query that returns all the >> raster rows covering the area requested. Now, I have all the data of >> an image region. If the requested region dimensions match the buffer >> dimensions, I can copy all the pixels fetched in this way: >> >> pImage = >> {b1b1b1b1b1b1b1b1b1b1...|b2b2b2b2b2b2b2b2b2...|...|bnbnbnbnbnbnbnbnbn} >> >> Where bi are the bytes of the band i. A WKT Raster image has a >> non-interleaved format, all the band are consecutive. Is it correct? I >> mean, copy the data in pImage with this format. >> >> And if the region dimensions don't match the buffer dimensiones, >> should I raise an error and finish or delegate in base >> GDALDataset::IRasterIO implementation? >> >> Another question: After copying the data from fetched rows in pImage >> buffer, should I do anything more? >> >> Other part of my implementation is overriding >> GDALRasterBand::IRasterIO method. My method will simply call the >> WKTRasterDataset::IRasterIO method with only one band to read. Is it >> correct? >> >> Thanks in advance. >> >> Best regards, >> Jorge >> _______________________________________________ >> 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
