Changes between Version 227 and Version 228 of WKTRaster/SpecificationWorking03

Timestamp:

Jul 27, 2012, 9:01:31 AM (12 years ago)

Author:

pracine

Comment:

—

WKTRaster/SpecificationWorking03

@@ -30 +30 @@
 7) Different variant of ST_SetValues() (Objective FV.23 below and ticket #595).
 
-8) Integrate the ST_CreateIndexRaster() plpgsql prototype (do not need to be implemented in C to be fast).
-
-9) Integrate the ST_Tile() plpgsql prototype (do not need to be implemented in C to be fast).
-
-10) Integrate the ST_AreaWeightedSummaryStats() plpgsql prototype (do not need to be implemented in C to be fast).
-
-11) Integrate the ST_SummaryStatsAgg() plpgsql prototype (do not need to be implemented in C to be fast).
-
-12) Add the possibility to interpolate a raster from a geometry layer.
-
-13) Integrate different custom functions, to be used with ST_MapAlgebraFct(), to extract of derive values from a coverage (raster or vector). (e.g. ST_Distance4ma resulting from [http://trac.osgeo.org/postgis/wiki/PostGIS_Raster_SoC_Idea_2012/Distance_Analysis_Tools the GSoC 2012]) (See Objective FV.26 and FV.27 below)
+8) Integrate the [http://trac.osgeo.org/postgis/browser/trunk/raster/scripts/plpgsql/st_createindexraster.sql ST_CreateIndexRaster() plpgsql prototype] (do not need to be implemented in C to be fast).
+
+9) Integrate the [http://trac.osgeo.org/postgis/browser/trunk/raster/scripts/plpgsql/st_tile.sql ST_Tile() plpgsql prototype] (do not need to be implemented in C to be fast).
+
+10) Integrate the [http://trac.osgeo.org/postgis/browser/trunk/raster/scripts/plpgsql/st_areaweightedsummarystats.sql ST_AreaWeightedSummaryStats() plpgsql prototype] (do not need to be implemented in C to be fast).
+
+11) Integrate the [http://trac.osgeo.org/postgis/browser/trunk/raster/scripts/plpgsql/st_summarystatsagg.sql ST_SummaryStatsAgg() plpgsql prototype] (do not need to be implemented in C to be fast) or develop a C Aggregate versions (item 15).
+
+12) Add some function interpolating a raster from a geometry layer (See Objective FV.28 below).
+
+13) Integrate different custom functions, to be used with ST_MapAlgebraFct(), to extract of derive values from a coverage (raster or vector). (e.g. ST_Distance4ma resulting from [http://trac.osgeo.org/postgis/wiki/PostGIS_Raster_SoC_Idea_2012/Distance_Analysis_Tools the GSoC 2012]) (See Objective FV.27 and FV.28 below)
 
 14) ST_CreateOverview(), ST_IsRegularlyTiled(), ST_HasOverlaps(), ST_HasGaps(), ST_HasTileSameSize(), ST_HasTileAligned() (See Objective FV.20 below)
@@ -88 +88 @@
  Open question: What to do when there are more than one pixel (because they are overlapping) value neighbouring the current pixel? Could be another parameter saying take the 'MIN', the 'MAX', the 'FIRST', the 'LAST', the 'MEAN'... 
 
- See also: [wiki:WKTRaster/MapAlgebra Notes taken by David Zwarg during the Montreal Code Sprint 2011] and http://trac.osgeo.org/postgis/ticket/860
+ See also: [wiki:WKTRaster/MapAlgebra Notes taken by David Zwarg during the Montreal Code Sprint 2011] and ticket #860.
 
 
 == '''Objective FV.25 - Optimized version of two rasters ST_MapAlgebra()''' ==
 
- * The prototype of an optimized version, trying to set those large areas of nodata values as well as areas where only one raster is present (this is the case when unioning two contiguous non-overlapping rasters) as a block (not pixel by pixel) is still in development. See http://trac.osgeo.org/postgis/browser/trunk/raster/scripts/plpgsql/st_mapalgebra_optimized.sql The idea is to set blocks of the resulting raster using ST_SetValues() (described in [http://trac.osgeo.org/postgis/wiki/WKTRaster/SpecificationWorking02 Objective 2.0.05]) instead of processing one pixel at a time. This is somewhat similar to setting a large block of memory with memcpy() or memset() rather than setting a buffer one value at a time. The resulting raster is divided into rectangular block with the _MapAlgebraParts() function.
+ * ST_MapAlgebra(raster, raster, 'UNION') can be optimized by not iterating on every pixels when it is not necessary. "Chunk" (or large areas) of pixels, outside the intersecting area of the two raster can be set in a "memset manner".
+
+ * The prototype of an optimized version, trying to set those large areas of nodata values as well as areas where only one raster is present (this is the case when unioning two contiguous non-overlapping rasters) as a block (not pixel by pixel or in a "memset manner") is still in development. See http://trac.osgeo.org/postgis/browser/trunk/raster/scripts/plpgsql/st_mapalgebra_optimized.sql The idea is to set blocks of the resulting raster using ST_SetValues() (described in [http://trac.osgeo.org/postgis/wiki/WKTRaster/SpecificationWorking02 Objective 2.0.05]) instead of processing one pixel at a time. This is somewhat similar to setting a large block of memory with memcpy() or memset() rather than setting a buffer one value at a time. The resulting raster is divided into rectangular block with the _MapAlgebraParts() function.
 
 == '''Objective FV.26 - ST_Difference() and ST_SymDifference() based on ST_MapAlgebra(raster, raster)''' ==
 
+
  -ST_Difference(raster1, band1, raster2, band2)
 
@@ -102 +105 @@
 
  See at the end of [http://trac.osgeo.org/postgis/browser/trunk/raster/scripts/plpgsql/st_mapalgebra.sql plpgsql/st_mapalgebra.sql][[BR]]
+
+
+== '''Objective FV.27 - Integrate different custom functions, to be used with ST_MapAlgebraFct(), to extract values from a coverage''' ==
+
+ * These are quick to implement ST_MapAlgebraFct() custom functions setting raster pixel values from any king of existing coverage. They all accept the name of the schema, the name of table and the name of raster (or geometry) column from which to extract values. They can also accept additional parameters.
+
+ * One way to organize/classify/make sense all those possible functions goes like this:
+
+  * Functions searching for the pixel value in a raster coverage. This is the same principle as ST_Union() except that the rasters do not have to be aligned (nice advantage!).
+
+  * Functions searching for the pixel value in a vector coverage. This is the same principle as ST_UnionToRaster() and ST_BurnToRaster().
+
+  * Functions aggregating pixel values from a neighbourhood. This is the same principle as ST_MapAlgebraFctN
+
+  * Functions deriving metric values HERE
+
+ * Some of them, not working on pixel neighbour area, hence only on aligned pixels from overlapping rasters, should eventually be replaced by the optimized version of ST_Union() (itself dependent on the optimized version of ST_MapAlgebra See Objective FV.25 above). Those alternative are less flexible than their future ST_Union alternative in that they only work on a whole table, not on a selection of a table (i.e. they are not aggregates like ST_Union is. One can always create a view on a table to work on a table subset though).
+
+ * Some examples of such custom functions exists:
+
+  * ST_FasterUnion('schemaname', 'tablename', 'rastercolumnname'), an alternative to ST_Union(rast, 'LAST') to merge all the tiles of a table together into a single raster. This function is described [http://geospatialelucubrations.blogspot.fr/2012/07/a-slow-yet-1000x-faster-alternative-to.html here]. this function is dependent on the ST_FirstRasterValue4ma() ST_MapAlgebraFct() custom function. 
+
+  * ST_FirstGeomValue4ma() http://postgis.refractions.net/pipermail/postgis-users/2012-April/033875.html
+
+ * Other possible functions:
+
+  * ST_GeomToRaster('schemaname', 'tablename', 'geomolumnname', 'METHOD') - A generalization of ST_FirstGeomValue4ma() described above but accepting more methods of value extraction.
+
+== '''Objective FV.28 - Add some function interpolating a raster from a geometry layer''' ==
 
 ----