50 | | * Open: an static method that establishes a connection with PostgreSQL and try to access the table given as argument. Several security checkings must be performed here: if the database has PostGIS support, if the table (or tables) exists, if has a field of raster type, if has a GIST index, etc. (Any more?) |
| 50 | * Open: an static method that establishes a connection with PostgreSQL and try to access the table given as argument. Several security checkings must be performed here: if the database has PostGIS support, if the table (or tables) exists, if has a field of raster type, if has a GIST index, etc. (Any more?). Additionally, this method will create the RasterBand objects, needed for fetching the raster bands' data, and create a pointer to the real data. |
71 | | With the Dataset, we will be able to access the table (or tables) that form the WKT Raster object, and to know with which type of raster are we dealing with. But we need to read the information of this raster. This is, to read the Raster Bands. |
| 71 | With the Dataset, we will be able to access the table (or tables) that form the WKT Raster object, and to know with which type of raster are we dealing with. But we need to read the information of this raster. This is, to read the Raster Bands. There are two important methods to implement: |
| 72 | * Constructor. In this method, the object gets important info, like the band number thar represents, the data type (data size) and the block size. |
| 73 | * IReadBlock: This method is the one that really needs the WKT Raster data (the image or tile data). This method take as input the offset over the data (in tiled images, this offset is an index to move over the data pointed by the data field in the Dataset) and a buffer to store the block (tile) read. |
| 74 | |
| 75 | ''The full set of possible GDALDataType values are declared in gdal.h, and include GDT_Byte, GDT_UInt16, GDT_Int16, and GDT_Float32'', but we, probably, only are going to consider GDT_Byte to this project. ''The block size is used to establish a natural or efficient block size to access the data with. For tiled datasets this will be the size of a tile, while for most other datasets it will be one scanline''. So, in our basic WKT Raster types reading, we should interpret this like ''the size of a tile''. |
| 76 | |
| 77 | And important issue here is ''how the tiles will finally be handled when fetching the raster data ''. Is the part in which I have more questions: |
| 78 | * The data fetched with the Raster Band, is in HEXWKB format? (I think so) I should code a method to transform to this format to another ones... |
| 79 | * Do we have to encode the data fetched in PNG/JPEG/TIFF format? |
| 80 | * May we assume that the tiles stored at the same table are homogeneus? What does exactly 'homogeneus' mean here? Only same pixel type? |
| 81 | * How do we manage the data fetched? Simply copy the raster data sequentially into the destination? If these raster data come from tiles with different pixeltype or band configuration? |
| 82 | |
| 83 | I think we should ''cut'', and take decissions about these questions. My proposal: |
| 84 | * Data fetched in HEXWKB format (really?). |
| 85 | * Encoding to, at least, one out-db format (¿TIFF?) |
| 86 | * Assume that tiles stored at same table have the same pixel type. We can put them sequentially in the output format (whatever). |
| 87 | * The same if tiles come from different table. Too risk? |
| 88 | |
| 89 | Any suggestions? |
| 90 | |