79 | | == '''Objective FV.24 - ST_MapAlgebraFctNbg() working on a tiled coverage''' == |
80 | | |
81 | | |
82 | | '''ST_MapAlgebraFctNgb('''rasttable text, rastcolumn text, band int, pixeltype text, radius int, funcname text[, funcargs text]''') -''' |
83 | | |
84 | | 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. This version work transparently on a tiled coverage avoiding edges effects. |
85 | | |
86 | | The function could 1) search itself for out of bound pixel values or 2) pass the name of the table to search for those values and let this job to the custom function. (I think 1) is a better option since the actual predefined custom functions would work tranparently). |
87 | | |
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'... |
89 | | |
90 | | See also: [wiki:WKTRaster/MapAlgebra Notes taken by David Zwarg during the Montreal Code Sprint 2011] and ticket #860. |
91 | | |
92 | | ---- |
93 | | == '''Objective FV.25 - Optimized version of two rasters ST_MapAlgebra()''' == |
94 | | |
95 | | * 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". |
96 | | |
97 | | * 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. |
98 | | |
99 | | ---- |
100 | | == '''Objective FV.26 - ST_Difference() and ST_SymDifference() based on ST_MapAlgebra(raster, raster)''' == |
101 | | |
102 | | |
103 | | -ST_Difference(raster1, band1, raster2, band2) |
104 | | |
105 | | -ST_SymDifference(raster1, band1, raster2, band2) |
106 | | |
107 | | See at the end of [http://trac.osgeo.org/postgis/browser/trunk/raster/scripts/plpgsql/st_mapalgebra.sql plpgsql/st_mapalgebra.sql][[BR]] |
108 | | |
109 | | ---- |
110 | | == '''Objective FV.27 - Integrate different custom functions, to be used with ST_MapAlgebraFct(), to extract values from a coverage''' == |
111 | | |
112 | | * 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. |
113 | | |
114 | | * One way to organize/classify/make sense all those possible functions goes like this: |
115 | | |
116 | | 1) 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!). |
117 | | |
118 | | 2) Functions searching for the pixel value in a vector coverage. This is the same principle as ST_UnionToRaster() and ST_BurnToRaster(). |
119 | | |
120 | | 3) Functions aggregating pixel values from a raster neighborhood. This is the same principle as ST_MapAlgebraFctNbg() except that the target raster do not have to be aligned with the source raster (nice advantage!). |
121 | | |
122 | | 4) Functions aggregating pixel values from a vector neighborhood. This is the only way to do that. |
123 | | |
124 | | 5) Functions deriving metric values from a raster or a geometry coverage. This is very similar to the two previous items but the result is not an aggregate value. e.g. Distance to something. |
125 | | |
126 | | Category 1), 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). |
127 | | |
128 | | * Some examples of such custom functions exists: |
129 | | |
130 | | * ST_FasterUnion('schemaname', 'tablename', 'rastercolumnname'), a temporary alternative to ST_Union(rast, 'LAST') - Merge all the tiles of a table together into a single raster. This function act as a wrapper around the ST_FirstRasterValue4ma() ST_MapAlgebraFct() custom function and is described [http://geospatialelucubrations.blogspot.fr/2012/07/a-slow-yet-1000x-faster-alternative-to.html here]. |
131 | | |
132 | | * ST_FirstGeomValue4ma() - Get the value from a specified column from the first geometry intersecting with the shape of the pixel (See [http://postgis.refractions.net/pipermail/postgis-users/2012-April/033875.html this post to postgis-users]) |
133 | | |
134 | | * Other possible functions: |
135 | | |
136 | | * ST_GeomToRaster('schemaname', 'tablename', 'geomolumnname', 'METHOD') (Category 2) - A generalization of ST_FirstGeomValue4ma() described above but accepting more methods of value extraction, depending on the type of coverage we want to extract from. This is very much like doing an intersection (actually more like an "identify" overlay operation) between a raster and a vector coverage. |
137 | | |
138 | | This function can further be generalised by adding parameters to define a buffer area around the pixel centroid or the pixel boundary. This would provide a category 4 type of function. (e.g. ST_Density()) |
139 | | |
140 | | The METHOD could be: |
141 | | |
142 | | * from any kind of coverage: COUNT, DISTINCT_COUNT, COUNT_MOST_FREQUENT, COUNT_LEAST_FREQUENT, MOST_FREQUENT_VALUE, LEAST_FREQUENT_VALUE, MAXIMUM, MINIMUM, RANGE, SUM, MEAN, STDDEV |
143 | | |
144 | | * from a line coverage could also be MAX_LENGTH, MIN_LENGTH, LENGTH_RANGE, LENGTH_SUM, LENGTH_MEAN, LENGTH_STDDEV, COMBINED_MAX_LENGTH, COMBINED_MIN_LENGTH, COMBINED_MEAN_LENGTH, COMBINED_STDDEV_LENGTH, LENGTH_OF_LINE_WITH_GREATEST_VALUE, LENGTH_OF_LINE_WITH_SMALLEST_VALUE, LENGTH_OF_LINE_WITH_MOST_FREQUENT_VALUE, LENGTH_OF_LEAST_FREQUENT_VALUE, VALUE_OF_LONGEST, VALUE_OF_SHORTEST, VALUE_OF_COMBINED_LONGEST, VALUE_OF_COMBINED_SHORTEST, WEIGHTED_SUM, WEIGHTED_MEAN |
145 | | |
146 | | * from a polygon coverage could also be MAX_AREA, MIN_AREA, AREA_RANGE, AREA_SUM, AREA_MEAN, AREA_STDDEV, COMBINED_MAX_AREA, COMBINED_MIN_AREA, COMBINED_MEAN_AREA, COMBINED_STDDEV_AREA, AREA_OF_POLYGON_WITH_GREATEST_VALUE, AREA_OF_POLYGON_WITH_SMALLEST_VALUE, AREA_OF_POLYGON_WITH_MOST_FREQUENT_VALUE, AREA_OF_LEAST_FREQUENT_VALUE, VALUE_OF_LARGEST, VALUE_OF_SMALLEST, VALUE_OF_COMBINED_LARGEST, VALUE_OF_COMBINED_SMALLEST, WEIGHTED_SUM, WEIGHTED_MEAN |
147 | | |
148 | | * ST_EuclidianDistance() (see [http://trac.osgeo.org/postgis/wiki/PostGIS_Raster_SoC_Idea_2012/Distance_Analysis_Tools the GSoC project]) this function takes advantage of the KNN index of geometry to quickly find the geometry nearest to the pixel centroid and compute its distance. |
149 | | |
150 | | ---- |
151 | | == '''Objective FV.28 - Add some function interpolating a raster from a geometry layer''' == |
152 | | |
153 | | * ST_Interpolate('schemaname', 'tablename', 'geomolumnname', 'METHOD') - Method could be 'NEAREST_NEIGHBOR', 'IDW', 'KRIGING', 'NATURAL_NEIGHBOR', 'SPLINE', 'REG_SPLINE_WITH_TENSION', etc... |
154 | | |
155 | | ---- |
| 79 | |
| 440 | == '''Objective FV.24 - ST_MapAlgebraFctNbg() working on a tiled coverage''' == |
| 441 | |
| 442 | |
| 443 | '''ST_MapAlgebraFctNgb('''rasttable text, rastcolumn text, band int, pixeltype text, radius int, funcname text[, funcargs text]''') -''' |
| 444 | |
| 445 | 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. This version work transparently on a tiled coverage avoiding edges effects. |
| 446 | |
| 447 | The function could 1) search itself for out of bound pixel values or 2) pass the name of the table to search for those values and let this job to the custom function. (I think 1) is a better option since the actual predefined custom functions would work tranparently). |
| 448 | |
| 449 | 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'... |
| 450 | |
| 451 | See also: [wiki:WKTRaster/MapAlgebra Notes taken by David Zwarg during the Montreal Code Sprint 2011] and ticket #860. |
| 452 | |
| 453 | ---- |
| 454 | == '''Objective FV.25 - Optimized version of two rasters ST_MapAlgebra()''' == |
| 455 | |
| 456 | * 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". |
| 457 | |
| 458 | * 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. |
| 459 | |
| 460 | ---- |
| 461 | == '''Objective FV.26 - ST_Difference() and ST_SymDifference() based on ST_MapAlgebra(raster, raster)''' == |
| 462 | |
| 463 | |
| 464 | -ST_Difference(raster1, band1, raster2, band2) |
| 465 | |
| 466 | -ST_SymDifference(raster1, band1, raster2, band2) |
| 467 | |
| 468 | See at the end of [http://trac.osgeo.org/postgis/browser/trunk/raster/scripts/plpgsql/st_mapalgebra.sql plpgsql/st_mapalgebra.sql][[BR]] |
| 469 | |
| 470 | ---- |
| 471 | == '''Objective FV.27 - Integrate different custom functions, to be used with ST_MapAlgebraFct(), to extract values from a coverage''' == |
| 472 | |
| 473 | * 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. |
| 474 | |
| 475 | * One way to organize/classify/make sense all those possible functions goes like this: |
| 476 | |
| 477 | 1) 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!). |
| 478 | |
| 479 | 2) Functions searching for the pixel value in a vector coverage. This is the same principle as ST_UnionToRaster() and ST_BurnToRaster(). |
| 480 | |
| 481 | 3) Functions aggregating pixel values from a raster neighborhood. This is the same principle as ST_MapAlgebraFctNbg() except that the target raster do not have to be aligned with the source raster (nice advantage!). |
| 482 | |
| 483 | 4) Functions aggregating pixel values from a vector neighborhood. This is the only way to do that. |
| 484 | |
| 485 | 5) Functions deriving metric values from a raster or a geometry coverage. This is very similar to the two previous items but the result is not an aggregate value. e.g. Distance to something. |
| 486 | |
| 487 | Category 1), 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). |
| 488 | |
| 489 | * Some examples of such custom functions exists: |
| 490 | |
| 491 | * ST_FasterUnion('schemaname', 'tablename', 'rastercolumnname'), a temporary alternative to ST_Union(rast, 'LAST') - Merge all the tiles of a table together into a single raster. This function act as a wrapper around the ST_FirstRasterValue4ma() ST_MapAlgebraFct() custom function and is described [http://geospatialelucubrations.blogspot.fr/2012/07/a-slow-yet-1000x-faster-alternative-to.html here]. |
| 492 | |
| 493 | * ST_FirstGeomValue4ma() - Get the value from a specified column from the first geometry intersecting with the shape of the pixel (See [http://postgis.refractions.net/pipermail/postgis-users/2012-April/033875.html this post to postgis-users]) |
| 494 | |
| 495 | * Other possible functions: |
| 496 | |
| 497 | * ST_GeomToRaster('schemaname', 'tablename', 'geomolumnname', 'METHOD') (Category 2) - A generalization of ST_FirstGeomValue4ma() described above but accepting more methods of value extraction, depending on the type of coverage we want to extract from. This is very much like doing an intersection (actually more like an "identify" overlay operation) between a raster and a vector coverage. |
| 498 | |
| 499 | This function can further be generalised by adding parameters to define a buffer area around the pixel centroid or the pixel boundary. This would provide a category 4 type of function. (e.g. ST_Density()) |
| 500 | |
| 501 | The METHOD could be: |
| 502 | |
| 503 | * from any kind of coverage: COUNT, DISTINCT_COUNT, COUNT_MOST_FREQUENT, COUNT_LEAST_FREQUENT, MOST_FREQUENT_VALUE, LEAST_FREQUENT_VALUE, MAXIMUM, MINIMUM, RANGE, SUM, MEAN, STDDEV |
| 504 | |
| 505 | * from a line coverage could also be MAX_LENGTH, MIN_LENGTH, LENGTH_RANGE, LENGTH_SUM, LENGTH_MEAN, LENGTH_STDDEV, COMBINED_MAX_LENGTH, COMBINED_MIN_LENGTH, COMBINED_MEAN_LENGTH, COMBINED_STDDEV_LENGTH, LENGTH_OF_LINE_WITH_GREATEST_VALUE, LENGTH_OF_LINE_WITH_SMALLEST_VALUE, LENGTH_OF_LINE_WITH_MOST_FREQUENT_VALUE, LENGTH_OF_LEAST_FREQUENT_VALUE, VALUE_OF_LONGEST, VALUE_OF_SHORTEST, VALUE_OF_COMBINED_LONGEST, VALUE_OF_COMBINED_SHORTEST, WEIGHTED_SUM, WEIGHTED_MEAN |
| 506 | |
| 507 | * from a polygon coverage could also be MAX_AREA, MIN_AREA, AREA_RANGE, AREA_SUM, AREA_MEAN, AREA_STDDEV, COMBINED_MAX_AREA, COMBINED_MIN_AREA, COMBINED_MEAN_AREA, COMBINED_STDDEV_AREA, AREA_OF_POLYGON_WITH_GREATEST_VALUE, AREA_OF_POLYGON_WITH_SMALLEST_VALUE, AREA_OF_POLYGON_WITH_MOST_FREQUENT_VALUE, AREA_OF_LEAST_FREQUENT_VALUE, VALUE_OF_LARGEST, VALUE_OF_SMALLEST, VALUE_OF_COMBINED_LARGEST, VALUE_OF_COMBINED_SMALLEST, WEIGHTED_SUM, WEIGHTED_MEAN |
| 508 | |
| 509 | * ST_EuclidianDistance() (see [http://trac.osgeo.org/postgis/wiki/PostGIS_Raster_SoC_Idea_2012/Distance_Analysis_Tools the GSoC project]) this function takes advantage of the KNN index of geometry to quickly find the geometry nearest to the pixel centroid and compute its distance. |
| 510 | |
| 511 | ---- |
| 512 | == '''Objective FV.28 - Add some function interpolating a raster from a geometry layer''' == |
| 513 | |
| 514 | * ST_Interpolate('schemaname', 'tablename', 'geomolumnname', 'METHOD') - Method could be 'NEAREST_NEIGHBOR', 'IDW', 'KRIGING', 'NATURAL_NEIGHBOR', 'SPLINE', 'REG_SPLINE_WITH_TENSION', etc... |
| 515 | |
| 516 | ---- |