Changes between Version 46 and Version 47 of WKTRaster/SpecificationWorking03

Timestamp:

Mar 25, 2011, 1:12:24 PM (13 years ago)

Author:

pracine

Comment:

—

WKTRaster/SpecificationWorking03

@@ -197 +197 @@
 
 ----
-== '''Objective FV.03 - Being able to use neighbour pixels in !MapAlgebra expressions.''' ==
+== '''Objective FV.03 - Implement all the necessary version of ST_MapAlgebra''' ==
+
+Different versions of ST_MapAlgebra are planned...
+
+One raster versions:
+
+1) '''ST_MapAlgebraExpr() -''' A one raster version taking an '''expression''' of one pixel at a time. Already implemented...
+
+2) '''ST_MapAlgebraFct() -''' A one raster version taking a '''user defined function''' (with optional parameters) of one pixel at a time. The function is a user defined PL/pgSQL function taking a float8 value and returning a value. Code was developped by David Zwarg, needs to be integrated in the source tree. This version is much faster than 1) but requires the user to write a PL/pgSQL function.
+
+3) '''ST_MapAlgebraFctNgb() -''' A one raster version taking a '''user defined function''' (with optional parameters) of the set of first, second, etc... '''neighbours''' of a pixel. The function is a user defined PL/pgSQL function taking a matrix containing the neighbour values and returning one value. Code do not exist yet but will be very much similar to 2). Out of bound pixels values are set to NULL. This version requires the user to write a PL/pgSQL function. Many predefined function should be delivered.
+
+4) '''ST_MapAlgebraFctNgb() -''' A one raster version taking a '''table name and a raster column name''' (in order to work on a '''tiled coverage''') and a '''user defined function''' (with optional parameters) of the set of first, second, etc... '''neighbours''' of a pixel. The passed matrix should include values for out of bound pixels taken from neighbour tiles.
+
+Two rasters versions. These versions must take into account different alignment, different extents, nodata and non-existent values.
+
+5) '''ST_MapAlgebraExpr() -''' A two rasters version taking an expression of two pixels at a time, one from each rasters. 
+
+6) '''ST_MapAlgebraExpr() -''' A two rasters version taking a '''table name and a raster column name''' (in order to work on a '''tiled coverage''') and an expression of two pixels at a time, one from each rasters.
+
+7) '''ST_MapAlgebraFct() -''' A two rasters version taking a '''user defined function''' (with optional parameters) of two pixels at a time, one from each rasters. The function is a user defined PL/pgSQL function taking two float8 values and returning one value.
+
+8) '''ST_MapAlgebraFct() -''' A two rasters version taking a '''table name and a raster column name''' (in order to work on a '''tiled coverage''') and a '''user defined function''' (with optional parameters) of two pixels at a time, one from each rasters. The function is a user defined PL/pgSQL function taking two float8 values and returning one value. Non-existent values are found in the neighbour tiles when possible.
+
+
+
+'''Details for 3) ST_MapAlgebraFctNgb()'''
 
 For now ST_MapAlgebra expressions refer only to the pixel being computed. e.g. "rast * 100". The original plan was to allow refering to neighbour pixels using two coordinated relative to the pixel being computed. e.g. "rast[-1,0] * 100" where rast[-1,0] refer to the value of the pixel one pixel to the left of the pixel being computed. However this syntax might prove to be hard to use when many neighbours are to be used.
@@ -237 +263 @@
 
 See also: [wiki:WKTRaster/MapAlgebra Notes taken by David Zwarg during the Montreal Code Sprint 2011] and http://trac.osgeo.org/postgis/ticket/860
+
+
+
+'''Details for 5) to 8) Two rasters versions'''
+
+These function must first determine if a resampling of one raster is necessary: 
+
+'''ST_SameAlignment(raster, raster)'''
+
+ This function returns true if both rasters' grids are aligned.
+
+ Two rasters grid are aligned if:
+
+  -They share the same pixel scales and skews
+
+  -At least one of any of the four corner of any pixel of one raster fall on any corner of the grid of the other raster.
+
+ Alignment is not the same concept as georeference. Two rasters can be aligned but not have the same georeference.
+
+ Rotation is important here since two rasters grid might look perfectly aligned but are not if their rotated are different.
+
+ Knowing if two rasters share the same alignment is useful when it is time to decide if one of them must be resampled before doing other operations (like ST_MapAlgebra on two rasters).
+
+ '''Variants'''
+
+  1) ST_SameAlignment(ulx1, uly1, scalex1, scaley1, skewx1, skewy1, ulx2, uly2, scalex2, scaley2, skewx2, skewy2)
+
+  2) ST_SameAlignment(rast1 raster, rast2 raster)
+
+ The first variant is useful to PL/pgSQL function which have already get the values of the parameters.
+
+ '''Implementation Details'''
+
+ Only the first variant should be implemented in C. The second one is a PL/pgSQL variants. The C implementation should follow the PL/pgSQL version implemented in http://trac.osgeo.org/postgis/browser/trunk/raster/scripts/plpgsql/st_mapalgebra.sql
+
+ It is not clear if this PL/pgSQL implementation works when raster are rotated. To verify.
+
+ See discussion in http://trac.osgeo.org/postgis/ticket/589
+
+ 
+'''ST_MapAlgebra on two rasters'''
+
+ Specifications of ST_MapAlgebra on two rasters are still in progress as a new optimised version, filling large areas of same value more quickly, is planned. See http://trac.osgeo.org/postgis/browser/trunk/raster/scripts/plpgsql/st_mapalgebra_optimized.sql
+
+ See discussion in http://trac.osgeo.org/postgis/ticket/590
+
 ----
 == '''Objective FV.04 - Being able to use "group by" to accumulate tiles to form a new raster.''' ==