Changes between Version 32 and Version 33 of WKTRaster/GDALDriverSpecificationWorking
- Timestamp:
- 06/22/11 08:56:20 (14 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
WKTRaster/GDALDriverSpecificationWorking
v32 v33 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. 57 57 58 Jorge: I think we have 3 cases: untiled raster, regularly tiled raster and irregularly tiled raster. 59 58 60 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. 59 61 62 Jorge: fully agree. The only way to ensure a raster is regularly tiled is a checking function. To be used carefully. 60 63 61 64 ---- … … 65 68 * Open the dataset (create db connection) 66 69 * Read some data about the dataset (metadata): srid, georeference information, projection information, raster data size, band information (number of bands, pixel size, color interpretation, if present), any other driver-specific dataset related information (i.e.: in our case, schema and table name) 67 * Construct the structure for raster bands, with instances of [http://www.gdal.org/classGDALRasterBand.html GDALRasterBand] class. You need to provide some basic information: data type (pixel size), block size (GDAL contains a concept of the natural block size of rasters so that applications can organize ddata access efficiently for some file formats) and color interpretation (if any).70 * Construct the structure for raster bands, with instances of [http://www.gdal.org/classGDALRasterBand.html GDALRasterBand] class. You need to provide some basic information: data type (pixel size), block size (GDAL contains a concept of the natural block size of rasters so that applications can organize data access efficiently for some file formats) and color interpretation (if any). 68 71 69 72 The metadata must be read from the raster table, using SQL functions like ST_Extent (used for raster data extent), ST_Metadata (used for general raster metadata) or functions like ST_SRID, ST_Width, ST_Height, etc. When your GDALDataset matches only one raster row (a raster tile) this is not a problem. But when your GDALDataset matches a whole raster table (ONE_RASTER_PER_TABLE mode), you have 2 options: … … 72 75 '''Pierre comment''': I think the driver should not try to detect bad raster arrangement with SQL queries. It should just get what it needs from the DB and burn rasters tiles as they come. If it detected that the arrangement is regular then burn them as regular. If they are not, then burn them accordingly. 73 76 77 '''Jorge comment''': What does ''accordingly'' mean here? My bet: if the user wants ONE_RASTER_PER_ROW, no problem. Burn one raster file for each tile. If the user wants ONE_RASTER_PER_TABLE and the tiles are not regular, the driver may warn the user and abort or force ONE_RASTER_PER_ROW mode (warning the user first). Any other options? 78 74 79 * Call the functions limiting the output to one result. Fast operation, but may be incorrect 75 80 76 81 '''Pierre comment''': What might be incorrect? There should not be different srid, pixeltype, or pixelsize in the same table. We have have to warn that we do not support this bad arrangement yet. 82 83 '''Jorge comment''': Related with the previous comment, we could simply warn the user about using that band arrangement and maybe force the ONE_RASTER_PER_ROW arrangement instead. 77 84 78 85 Currently, the driver takes the first (and slow) option. That caused performance problems (see ticket #497) … … 81 88 82 89 Pierre: So just knowing the raster extent, the pixelsize and the pixeltype is not sufficient? You could do this with a quick query SELECT ST_Extent(rast), min(ST_BandPixelSize(rast, band)), min(ST_BandPixelType(rast, band)) assuming all tiles have the same pixelsize and pixeltype. 90 91 Jorge: Yes, it's sufficient. This question is deprecated. Sorry. 83 92 84 93 ---- … … 89 98 * ''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]. 90 99 91 '''Pierre question:''' How is the natural block size choosen in our case? 100 '''Pierre question:''' How is the natural block size choosen in our case? 101 102 '''Jorge''': By ST_Metadata (width and height).In case of non-regular blocked rasters the function raises an error. 92 103 93 104 * 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]. … … 97 108 '''Pierre question:''' In which case "the buffer size (nBufXSize x nBufYSize) is different than the size of the region being accessed (nXSize x nYSize)"? 98 109 110 '''Jorge''': Ok, these are not use cases of our driver. The point is: if you implement IRasterIO, you must deal with the fact that maybe the caller is using arbitrary data type and buffer size to call your implementation (these are function's arguments). We could simply detect this situation by comparing the data type and buffer size provided as arguments with the known data type and raster size, and raise an error if needed. But I think if the caller uses an integer buffer and we have a raster with floating point values, for example, we still should provide the raster data and warn the user about possible unaccurate values, because of truncating oepration. 111 99 112 '''Pierre question:''' Do we agree that "Region oriented" is a general case of "''Natural'' block oriented" and that IReadBlock can be implemented as a wrapper around IRasterIO? 113 114 '''Jorge''': Agree. But taking into account the previous comment. 100 115 101 116 Clearly, there's no best method for reading/writing data in our case. In the ideal case of regulary blocked rasters, with no overlapping and same grid for all tiles, the block oriented r/w is the more appropiate strategy. But in the rest of the cases, a more general r/w method must be provided. … … 110 125 111 126 '''Pierre question:''' How long take a ST_Extent query on a 1 000 000 tiles indexed table? 127 '''Jorge''': Maybe acceptable time. But 1 000 000 server calls to get the raster data portion surrounded by the box constructed with 4 coords (each IReadBlock round) is too slow, I think. Each IReadBlock call may imply a simple ''select st_band(rast, nband) from table where...'' in case of regularly blocked rasters (1 natural GDAL block = 1 raster table row), but the general case (to be implemented in IRasterIO) is different. The caller may want a region covered by 2 raster tiles. Ok, right now we simply support this particular case (regularly blocked raster), but for the more general case, we'd need a ''st_intersection'' version returning raster data, IMHO. 128 112 129 113 130 '''Open question''': What should be the general r/w algorithm? … … 115 132 116 133 '''Pierre question:''' What do you mean by "I don't know how to choose the geographic limits"? Can't you deduce them from the parameter passed to the function and the metadata of the rasters? 134 117 135 118 136 ----
