Changes between Version 34 and Version 35 of WKTRasterDriver

Timestamp:

Jul 19, 2009, 3:44:26 PM (15 years ago)

Author:

jorgearevalo

Comment:

--

WKTRasterDriver

@@ -4 +4 @@
 
 
-********** UPDATED ON 2009/07/12 ***********
+********** UPDATED ON 2009/07/19 ***********
 
 
@@ -16 +16 @@
 [http://www.gis4free.org/blog/2009/06/27/gsoc-09-weekly-report-5-1906-2606/ Weekly report #5 (19/06 - 26/06)][[BR]]
 [http://www.gis4free.org/blog/2009/07/04/gsoc-09-weekly-report-6-2606-0307/ Weekly report #6 (26/06 - 03/07)][[BR]]
-[http://www.gis4free.org/blog/2009/07/13/gsoc-09-weekly-report-7-0307-1007/ Weekly report #7 (03/07 - 10/07)]
+[http://www.gis4free.org/blog/2009/07/13/gsoc-09-weekly-report-7-0307-1007/ Weekly report #7 (03/07 - 10/07)][[BR]]
+[http://www.gis4free.org/blog/2009/07/20/gsoc-09-weekly-report-8-1007-1707/ Weekly report #8 (10/07 - 17/07)]
 
 == General overview ==
@@ -66 +67 @@
   1. Fetch raster properties from RASTER_COLUMNS table. If the table is not registered in RASTER_COLUMNS, as we are working only in regularly_tiled mode, we should finish.
   1. Populate its georeference information, to allow GetProjectionRef and GetGeoTransform methods provide correct information.
+  1. Create the raster bands, paying attention to pixel types and nodata values.
 
 
@@ -72 +74 @@
 If Dataset opens the connection with database, RasterBand reads blocks of data. So, the key method here is IReadBlock. This method:
 
-  1. Get pixel size (now only 8bits).
-  1. Transform pixel,line coordinates into coordinates of the raster reference systems, by using the proper methods of Dataset, and get the coordinates of the block center.
-  1. Query for blocks that contains this point (the block center). As we only consider regularly_blocking rasters, the result will only 1 block. IMPORTANT: NOW, I'M USING A TESTING QUERY THAT ALWAYS FETCH THE SAME RASTER BLOCK. THE SPATIAL QUERY WILL BE ADDED ASAP.
+  1. Get pixel size.
+  1. Transform pixel,line coordinates into coordinates of the raster reference systems, by using the proper methods of Dataset, and get the coordinates of the lower left and upper right corners in map units
+  1. Query for blocks that contains this block. As we only consider regularly_blocking rasters, the result will only be 1 block.
   1. Fetch the block in HEXWKB format and parse it to get the data. The HEXWKB format includes raster information header on each block, so, this information can be used for integrity checkings.
-  1. Copy the block data into the buffer.
+  1. Look for the correct raster band and copy its block data into the buffer, taking care of the pixel size and endianess of the band.
 
 
@@ -83 +85 @@
 ''If the RASTER_COLUMNS "regular_blocking" value is true then "all blocks are equal sized, abutted and non-overlapping, started at top left origin", plus additional constraints. This regular blocking capability raises the possibility of having very large contiguous raster coverages (made up of many individual WKTRaster-s) which, in turn, raises potential performance problems. Other raster formats counter this by having overviews; a concept that is already supported by GDAL.''
 
-I think that this driver must have support of overviews, because I suppose that it will be common to have large images stored at database, that will produce large datasets when reading. Anyway, this issue was being discused until May 20th (http://postgis.refractions.net/pipermail/postgis-devel/2009-May/005629.html), and the final decission seems to be having an additional table for overviews (this is the way in which Mateusz' script manage it). To follow this issue: http://trac.osgeo.org/postgis/wiki/WKTRaster/SpecificationWorking01#RASTER_OVERVIEWSMetadataTable. I'll keep an eye on it.
+I think that this driver must have support of overviews, because I suppose that it will be common to have large images stored at database, that will produce large datasets when reading. Anyway, this issue was being discused until May 20th (http://postgis.refractions.net/pipermail/postgis-devel/2009-May/005629.html), and the final decission seems to be having an additional table for overviews (this is the way in which Mateusz' script manage it). To follow this issue: http://trac.osgeo.org/postgis/wiki/WKTRaster/SpecificationWorking01#RASTER_OVERVIEWSMetadataTable.
+
+My implementation of overviews (under development just now) follows the next steps:
+  1. Create one Dataset per overview in the Open method of WKTRasterDataset class. Is necessary to check the number of overviews of the given table, using the RASTER_OVERVIEWS metadata table. Is necessary to set the name of the overviews table in each created Dataset.
+  1. Create the rasterbands for each overview Dataset. Change the pixel size by using the overview factor.
+
+
+== Out-db rasters ==
+
+I'm working in the implementation of the support for out-db rasters too. The point is to read the band data from a file in the filesystem, instead of fetching it from database. I suppose that the file in the filesystem contains ONLY the raster bands data.
 
 == Project plan (please, edit as convenient) ==
@@ -94 +105 @@
 ||Dataset: Connection with database and creation of Raster Bands objects (regular blocking rasters)||6th July||Done||
 ||RasterBand: Query the correct block and fetch the raster data||15th July||On going||
-||'''Objective 1.1 - Support of different pixel data types, take care of byte swapping'''||'''17th July'''||'''todo'''||
-||'''Objective 2 - Support access to overviews'''||'''19th July'''||'''todo'''||
-||'''Objective 3 - Support for out-db rasters'''||'''19th July'''||'''todo'''||
+||'''Objective 1.1 - Support of different pixel data types, take care of byte swapping'''||'''17th July'''||'''Done'''||
+||'''Objective 2 - Support access to overviews'''||'''26th July'''||'''On going'''||
+||'''Objective 3 - Support for out-db rasters'''||'''26th July'''||'''On going'''||
 ||'''Objective 4 - Rasters inplace update'''||'''26th July'''||'''todo'''||
 ||'''Objective 5 - Read only support for non-regular blocking rasters'''||'''2th-10th August'''||'''todo'''||