Changes between Version 37 and Version 38 of WKTRaster/SpecificationWorking03

Timestamp:

03/14/11 11:31:19 (14 years ago)

Author:

pracine

Comment:

—

WKTRaster/SpecificationWorking03

@@ -197 +197 @@
 
 ----
-== '''Objective FV.03 - Being able to use neighbour pixels in MapAlgebra expressions.''' ==
+== '''Objective FV.03 - Being able to use neighbour pixels in !MapAlgebra expressions.''' ==
 
 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.
@@ -213 +213 @@
  * a value: Replace any nodata value with this value and compute.
 
+Any remaining parameters to ST_MapAlgebraNgb could be passed to the summarizing functions for its own need.
+
+A number of predefined summarizing function could be delivered: ST_Average, ST_Majority, ST_Slope, ST_Aspect, 
+
 Users could write their own map algebra summarizing functions. 
 
-A more sophisticated version would pass a georeferenced raster instead of just a value matrix so that summarizing function could use this geoereference (e.g. to determine a ).
-
-Any remaining parameters to ST_MapAlgebraNgb could be passed to the summarizing functions for its own need.
+A more sophisticated version would pass a georeferenced raster instead of just a value matrix so that summarizing function could use this geoereference (e.g. to determine a value from the whole coverage (with ST_Value) when the neighbours are out of the bound of the raster). Passing a raster would allow existing raster functions (like the summarizing function which are to come) and remove the need to pass the dimension since they would correspond to the ST_Width & ST_Height functions. Only the optional "what to do with nodata values" could be needed and some additional parameters.
+
+There is three difficulties must be solved to impement this function:
+
+ * The matrix values assigment must be optimized when passing from one pixel to the other.
+ * We must see how it is possible to call a PL/pgSQL function from a C function
+ * We must see how to pass a variable number of parameter to a PL/pgSQL function