Changes between Version 9 and Version 10 of WKTRaster/GDALDriverSpecificationWorking

Timestamp:

Feb 17, 2011, 2:26:19 PM (13 years ago)

Author:

pracine

Comment:

—

WKTRaster/GDALDriverSpecificationWorking

@@ -54 +54 @@
  From a GDAL user point of view I know there is a bunch of raster rows in the DB and there is only two things I want to do: extract those rasters rows one by one creating one raster per row or treat them all as a single raster and blend them alltogether. Furthermore I want to be able to SELECT those rows using a WHERE statement. If I want a single raster from the db, I have to build my WHERE clause accordingly. There is no need for an extra mode for this. Beside, I don't want to know or have to know what is the raster table arrangement. I expect the driver is able to deal with them all.
 
- Then, the driver has to deal with all the possible arrangement of those selected rows in both mode. 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 generalizasion of the first one. 
+ Then, the driver has to deal with all the possible arrangement of those selected rows in both mode. 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. 
 
  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.