Changes between Version 35 and Version 36 of WKTRaster/GDALDriverSpecificationWorking

Timestamp:

06/28/11 09:09:18 (13 years ago)

Author:

pracine

Comment:

—

WKTRaster/GDALDriverSpecificationWorking

@@ -56 +56 @@
  Then, the driver has to deal with all the possible arrangement of those selected rows in both mode (overlap, gaps, missing tiles, etc...). You tried to enumerate the posssible arrangement above but I think there is only two cases: the tiles are regularly tiled or they are not, whatever the number of tile there is (1 or more). To me the irregular case is a generalization of the first one. 
 
- Jorge: I think we have 3 cases: untiled raster, regularly tiled raster and irregularly tiled raster.
+  Jorge: I think we have 3 cases: untiled raster, regularly tiled raster and irregularly tiled raster.
 
  If, and only if, you can optimize the regularly tiled case, then you write is as an exception. The problem is to make sure the table is REALLY regularly tiled without relying on the user knowledge. Just the introduction of the -a option to raster2pgsql.py allowing to append tiles to an existing table make the "regularly blocked" flag untrustable. If really we want to maintain this flag we will have to create something like a ST_ValidateRegularBlocking aggregate function.
 
- Jorge: fully agree. The only way to ensure a raster is regularly tiled is a checking function. To be used carefully.
+  Jorge: fully agree. The only way to ensure a raster is regularly tiled is a checking function. To be used carefully.
+
+   Pierre: Then if we can not rely on the raster_columns flag and if a ST_ValidateRegularBlocking() would be too slow, we have to treat "regularly tiled" and "irregularly tiled" as a one unique case hoping that the "regular" one will be faster because it involves less processing when merging the tiles together.
  
 ----