| 230 | | Specifications of two rasters versions of ST_MapAlgebra are still in progress as a new optimised version, filling large areas of same value more quickly and dependent on ST_SetValues() described in [http://trac.osgeo.org/postgis/wiki/WKTRaster/SpecificationWorking02 Objective 2.0.05], is planned. See http://trac.osgeo.org/postgis/browser/trunk/raster/scripts/plpgsql/st_mapalgebra_optimized.sql The idea is to set large areas of the resulting raster when possible using a process more similar to memcpy than by computing one pixel value at a time. |
| 231 | | |
| 232 | | -Both rasters must have the same SRID. If not, ST_MapAlgebra should return an error: "ERROR: Operation on two geometries with different SRIDs" |
| 233 | | |
| 234 | | -Both raster must be aligned. This is determined using the ST_SameAlignment() function described below. If a resampling is necessary they use the planned ST_Resample() function to resample the second raster to the first one before processing (or the first to the second if an optional parameter is provided). If ST_Resample() is not yet implemented when these functions are implemented, just return an error message: "ERROR: MapAlgebra on rasters with different alignment not yet implemented." |
| 235 | | |
| 236 | | -Both raster must overlap. This is determined using ST_Intersects(raster, raster) (to be implemented). If they don't overlap an empty raster is returned. |
| 237 | | |
| 238 | | One of the implications of this is that users should add a WHERE clause to avoid useless computation with non-overlapping rasters. This is the same principle as with ST_Intersection(). Hence: |
| 239 | | SELECT ST_MapAlgebra(rast1, rast2, mathExpr) FROM mytable WHERE ST_Intersects(rast1, rast2) |
| 240 | | will be faster than: |
| 241 | | SELECT ST_MapAlgebra(rast1, rast2, mathExpr) FROM mytable |
| 242 | | |
| 243 | | -The computation extent (extentexpr in the functions below) can be: |
| | 230 | * A simple PL/pgSQL prototype exists in http://trac.osgeo.org/postgis/browser/trunk/raster/scripts/plpgsql/st_mapalgebra.sql. This version iterates over every pixel of the unionized extent of two rasters even if there are large areas where both rasters are absent and hence are interpreted as nodata values. An optimized prototype, trying to set those large nodata areas 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) using ST_SetValues() described in [http://trac.osgeo.org/postgis/wiki/WKTRaster/SpecificationWorking02 Objective 2.0.05] is still in development. See http://trac.osgeo.org/postgis/browser/trunk/raster/scripts/plpgsql/st_mapalgebra_optimized.sql The idea is to set large areas of the resulting raster when possible using a process more similar to memcpy than by computing one pixel value at a time. |
| | 231 | |
| | 232 | * Both rasters must have the same SRID. If not, ST_MapAlgebra should return an error: "ERROR: Operation on two geometries with different SRIDs" |
| | 233 | |
| | 234 | * Both raster must be aligned. This is determined using the ST_SameAlignment() function described below. If a resampling is necessary they use the planned ST_Resample() function to resample the second raster to the first one before processing (or the first to the second if an optional parameter is provided). If ST_Resample() is not yet implemented when these functions are implemented, just return an error message: "ERROR: MapAlgebra on rasters with different alignment not yet implemented." |
| | 235 | |
| | 236 | * The computation extent (extentexpr in the functions below) can be:[[BR]][[BR]] |
| 250 | | Replacement expressions can be provided as parameter for when: |
| 251 | | |
| 252 | | -The first raster value is nodata (nodata1expr in the functions below)[[BR]] |
| 253 | | -The second raster value is nodata (nodata2expr in the functions below)[[BR]] |
| 254 | | -Both rasters values when they are both nodata (nodatanodataexpr in the functions below) |
| 255 | | |
| 256 | | Open Question 1 (DZ): Should ST_MapAlgebra resample the resulting rasters internally, or should we let the users resample it afterward with ST_Resample: ST_Resample(ST_MapAlgebra(), originx, originy, pixelsizex, pixelsizey)[[BR]] |
| | 243 | * In certain cases, for example when the computation extent is set to 'INTERSECTION', it is better to reduce the execution of ST_Mapalgebra(rast1, rast2) to overlapping rasters. This reduction is performed by adding a 'WHERE ST_Intersects(raster, raster)' clause to the query (to be implemented). If such a clause is not used and the rasters don't overlap an empty raster is returned. This behaviour is similar to the one of ST_Intersection(). Hence:[[BR]][[BR]] SELECT ST_MapAlgebra(rast1, rast2, mathExpr) FROM mytable WHERE ST_Intersects(rast1, rast2)[[BR]] should be much faster and return many less empty rasters than:[[BR]][[BR]] SELECT ST_MapAlgebra(rast1, rast2, mathExpr) FROM mytable |
| | 244 | |
| | 245 | * Alternative expressions, evaluated in place of the main expression, can be provided as parameter to deal with nodata values: |
| | 246 | |
| | 247 | -nodata1expr is evaluated when the first raster pixel value is nodata or when the first raster is absent from the pixel area being evaluated[[BR]] |
| | 248 | -nodata2expr is evaluated when the second raster pixel value is nodata or when the second raster is absent from the pixel area being evaluated[[BR]] |
| | 249 | -nodatanodataexpr is evaluated when both rasters pixel values are nodata or when the both rastera are absent from the pixel area being evaluated[[BR]] |
| | 250 | -expression is evaluated when both raster pixel values are withdata. |
| | 251 | |
| | 252 | * Alternate expressions like nodata1expr and nodata2expr are used to simplify complex decision expression trying to deal with the presence of nodata value pixels. Having three short expressions like this:[[BR]][[BR]] 'rast2', 'rast2', 'rast1'[[BR]][[BR]]is simpler to understand than a single complex expression dealing with nodata like this:[[BR]][[BR]] ‘CASE WHEN rast2 IS NULL THEN rast1 ELSE rast2 END’[[BR]][[BR]]This is a simple case. In more complex cases, expressions can quickly get incomprehensible and alternate expressions greatly simplify the task of writing expressions, even if having three extra parameters may seams cumbersome. |
| | 253 | |
| | 254 | |
| | 255 | * Open Question 1 (DZ): Should ST_MapAlgebra resample the resulting rasters internally, or should we let the users resample it afterward with ST_Resample: ST_Resample(ST_MapAlgebra(), originx, originy, pixelsizex, pixelsizey)[[BR]] |
