Changes between Version 43 and Version 44 of WKTRaster/SpecificationWorking03
- Timestamp:
- 03/14/11 13:22:29 (14 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
WKTRaster/SpecificationWorking03
v43 v44 201 201 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. 202 202 203 An alternative syntax would involve another function name (e.g. ST_MapAlgebraNgb ) and a way to define a neighbour rectangular region around the computed pixel (e.g.: "2,2" meaning a rectangle encompassing the two neighbour pixels in each direction) and a function to call with this matrix of pixel values. A complete example might look like:204 205 SELECT ST_MapAlgebraNgb(rast, "ST_Mean", 2, 2, "ignore")203 An alternative syntax would involve another function name (e.g. ST_MapAlgebraNgb or ST_MovingWindow) and a way to define a neighbour rectangular region around the computed pixel (e.g.: "2,2" meaning a rectangle encompassing the two neighbour pixels in each direction) and a function to call with this matrix of pixel values. A complete example might look like: 204 205 SELECT ST_MapAlgebraNgb(rast, band, pixeltype, "ST_Mean", 2, 2, "ignore") 206 206 207 207 So this would mean "for each pixel, compute the average of all the 1 + 8 + 16 = 25 pixels surrounding the current pixel and "ignore" pixels with nodata values." … … 222 222 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). Only the optional "what to do with nodata values" could be needed and some additional parameters. In this case the example become: 223 223 224 SELECT ST_MapAlgebraNgb(rast, 2, 2, "ST_Mean", "ignore")224 SELECT ST_MapAlgebraNgb(rast, band, pixeltype, 2, 2, "ST_Mean", "ignore") 225 225 226 226 and the dimensions do not have to be passed to the summarizing functions since it could deduce them from ST_Width & ST_Height. 227 227 228 An even more sophisticated version should get a raster table and a raster column as parameters and try to search for neighbour in the whole raster coverage when out of bound pixels are part of the neighbourhood. e.g.: 229 230 SELECT ST_MapAlgebraNgb("mycoveragetable", "myrastercolumn", band, pixeltype, 2, 2, "ST_Mean", "ignore") 231 228 232 Three difficulties must be solved to implement this function: 229 233 230 * The matrix values assigmentmust be optimized when passing from one pixel to the other.234 * The construction of the matrix must to be passed to the summarizing functions must be optimized when passing from one pixel to the other. 231 235 * We must see how it is possible to call a PL/pgSQL function from a C function 232 236 * We must see how to pass a variable number of parameter to a PL/pgSQL function