Changes between Version 31 and Version 32 of WKTRasterDriver
- Timestamp:
- Jul 8, 2009, 1:03:09 PM (15 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
WKTRasterDriver
v31 v32 2 2 3 3 [[TOC]] 4 5 6 ********** UPDATED ON 2009/07/08 *********** 7 4 8 5 9 This is one of the selected projects for Google Summer of Code 2009. Links to the weekly reports will be posted here during the project development, as well as useful information and conclusions. … … 68 72 ''-MODE=FIRST_ROW, in this case you treat only the first row returned by a SQL query. This could be very similar to the 'where' parameter of the GEORASTER GDAL driver.'' 69 73 70 ''-MODE=ONE_FILE_PER_ROW, in this case you would read each row as an independent image. I'm not sure though that GDAL allows you to do this. For sure a good WKT exporter/dumper would allow this. The result would be one filesystem raster file per row.'' 74 ''-MODE=ONE_FILE_PER_ROW, in this case you would read each row as an independent image. I'm not sure though that GDAL allows you to do this. For sure a good WKT exporter/dumper would allow this. The result would be one filesystem raster file per row.''. UPDATE: Subdatasets (http://www.gdal.org/gdal_datamodel.html, SUBDATASETS Domain) could be useful here. Can datasets based on a single row treated as tiles (blocks), this is, loaded in RAM, the whole image? Maybe is better to provide finer grained access to this datasets, but it will mean extra work. 71 75 72 76 **** QUESTION: There is one type of regular-blocking WKT Raster that implies more than one table, the type called "tiled image". In this type, we'd have to read two or more tables to get the whole raster coverage. So, do we have to read all tables, with all of their tiles, to create a Dataset? In this case, the connection string syntax may vary... 73 77 74 78 **** ANSWER, by Pierre Racine: I would not take care of this arrangement. Lets focus on reading one table at a time. As I said in the doc this arrangement is not very useful/modern. 79 80 81 **** QUESTION: How to manage the mode in irregular-blocking rasters? 82 83 **** ANSWER: Maybe an additional param to connection string: PG:......mode='<mode>'. Even for regular blocking arrangements too. 75 84 76 85 Anyway, as we said, I'm going to focus on reading the regular blocking arrangements. And how should I read these arrangements? … … 82 91 **** QUESTION: Should the RasterBand read all the tiles (rows of the raster table) and put them consecutives in the same memory area? If I expect this from RasterBand class, the memory allocation is easy. 83 92 93 **** ANSWER: It should have only one block (tile) in memory at same time. 94 84 95 85 96 == Implementing the RasterBand == … … 89 100 * 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. 90 101 91 ''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''. 102 ''The full set of possible GDALDataType values are declared in gdal.h, and include GDT_Byte, GDT_UInt16, GDT_Int16, and GDT_Float32''. All of them must be managed. 103 104 ''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''. 92 105 93 106 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: … … 98 111 99 112 I think we should ''cut'', and take decissions about these questions. My proposal: 100 * Data fetched in HEXWKB format (really?).101 * Encoding to, at least, one out-db format (¿TIFF?)102 * Assume that tiles stored at same table have the same pixel type. We can put them sequentially in the output format (whatever).103 * The same if tiles come from different tables. Too much risk?113 * Data fetched in HEXWKB format. Implement a HEXWKB to binary decoding taking care to convert to local machine byte order if necessary. See OGRPGLayer::HEXToGeometry() method in ogrpglayer.cpp as a guide. 114 * Apart from the possible implementation of out-db rasters, don't care about encoding to output format 115 * ''In a regular_blocking table you can assume that all types are of the same pixel type, the same tile size (in pixels and lines), and the same geographic resolution.'' 116 * ''When you establish the GDALRasterBand corresponding to a band in the table you will declare the pixel data type based on the contents of the RASTER_COLUMNS table. The IReadBlock() method will be invoked with a buffer that is the block/tile size and already of the declared pixel data type. The tile you get from the database should also be in this type (assuming regular_blocking). There should not be any translation of pixel type required though you will need to be byte order aware for non-byte image data. You will basically decode the HEXWKB image into the buffer passed into IReadBlock.'' 104 117 105 118 Any suggestions? … … 118 131 ||Create basic enviroment for new GDAL driver|| 21th June||Done|| 119 132 ||Create testing enviroment for debugging driver developing|| 28th June||Done|| 120 ||'''Objective 1 - Read only support for regular blocking rasters'''||'''13th July'''||'''On going'''||'''midterm evaluation'''||133 ||'''Objective 1 - Prototype read only support for regular blocking rasters'''||'''13th July'''||'''On going'''||'''midterm evaluation'''|| 121 134 ||Dataset: Connection with database and creation of Raster Bands objects (regular blocking rasters)||6th July||On going|| 122 135 ||RasterBand: Fetching of raster data||13th July||On going|| 123 || ¿Transform the fetched data in another format?||13th July||todo||136 ||'''Objective 1.1 - Support of different pixel data types, take care of byte swapping'''||'''16th July'''||'''todo'''|| 124 137 ||'''Objective 2 - Support access to overviews'''||'''19th July'''||'''todo'''|| 125 138 ||'''Objective 3 - Support for out-db rasters'''||'''19th July'''||'''todo'''||
