Changes between Version 24 and Version 25 of WKTRaster/GDALDriverSpecificationWorking

Timestamp:

Feb 17, 2011, 3:53:18 PM (13 years ago)

Author:

pracine

Comment:

—

WKTRaster/GDALDriverSpecificationWorking

@@ -89 +89 @@
   * ''Natural'' block oriented r/w: The driver reads/writes data in equal sized blocks. The potentially more efficient way of r/w data. Really, the natural block size for this dataset is chosen during GDALRasterBand creation. So, '''it's driver's responsibility to provide the desired value for block size'''. To use this method, your driver must provide an implementation of [http://www.gdal.org/classGDALRasterBand.html#09e1d83971ddff0b43deffd54ef25eef IReadBlock].
 
+ '''Pierre question:''' How is the natural block size choosen in our case?
+
   * Region oriented r/w: The driver reads/writes arbitrary regions of data. It's a potentially less efficient method, because you have to take care of '''data type translation''' if the data type of the buffer is different than that of the GDALRasterBand. You also must takes care of '''image decimation / replication''' if the buffer size (nBufXSize x nBufYSize) is different than the size of the region being accessed (nXSize x nYSize). To use this method, your driver must provide an implementation of [http://www.gdal.org/classGDALRasterBand.html#5497e8d29e743ee9177202cb3f61c3c7 IRasterIO].
 
@@ -115 +117 @@
 
 ----
+
+
+=== Implementation ===
+
+
+GDALRasterBand::IRasterIO(required tile metadata)
+
+ '''Pierre:''' Can't it not be as simple as that? In the best case the required blocks fits what is in the table and everything is optimized. If not it is slower. We don't have to know in advance whether the table is regularly tiled or not. 
+
+  Deduce a world coordinate rectangle which four corners are the center of the upper left, lower left, lower right, upper right pixels of the area requested.
+  
+  Fetch, in a unique SQL query, every rasters intersecting this area along with the upper left X & Y, width, height, scalex, scaleY, skewX and skewY
+  
+  If there is only one row fetched and the metadata of this raster fits the required tile metadata (this means we are querying based on the natural block side)
+
+   just copy the values as a block (memcopy) (is this possible? Should we have, Is't there a ST_Bytea() SQL function?)
+        
+  If not iterate on the required tile
+    copy pixel values one by one from each raster fetched (that means if there is overlaps, only the pixels of the last raster fetched is burned. We can enhace this later by providing a BLENDING_MODE with the driver)
+     
+     
+!GDALRasterBand::!ReadBlock(block x & y)
+
+  Deduce IRasterIO required tile metadata
+  call IRasterIO(required tile metadata)
+
+