223 | | 2. The desired raster is specified with parameters or by referencing an existing raster. |
224 | | 3. Sometimes the resolution of the desired raster is so high that the whole raster coverage cannot be stored in one PostgreSQL row. The approach must be able to produce a tiled raster coverage stored into many rows. |
225 | | 4. Source geometries might be outside the extent of the desired raster, or the cost raster, or both. |
226 | | 5. The approach should work well in a number of situations: |
| 223 | 2. The desired raster is specified with parameters or by referencing an existing raster. |
| 224 | 3. Sometimes the resolution of the desired raster is so high that the whole raster coverage cannot be stored in one PostgreSQL row. The approach must be able to produce a tiled raster coverage stored into many rows. |
| 225 | 4. Source geometries might be outside the extent of the desired raster, or the cost raster, or both. |
| 226 | 5. The approach should work well in a number of situations: |
247 | | The raster/vector integrated approach of Euclidean distance can be reused here so that: |
248 | | the source points do not have to be in the raster extent (constraint 4) |
249 | | it is possible to to create a tiled raster coverage aligned to an existing reference raster (constraint 3) |
250 | | The scanning process can move randomly around the entire coverage. Pieces of rasters can be swapped in and out of memory in case of high resolution raster (constraints 5b, 5d). |
251 | | |
252 | | |
253 | | '''Cons:''' |
254 | | |
255 | | Not sure whether it will work well with large number of source points (constraint 1, 5c & 5d). Maybe we can use a binary tree with an linked list at each node in the tree to efficiently hold cells with identical cumulative costs. |
256 | | Not sure how it will work with multiple cost rasters (constraint 7). |
257 | | |
| 248 | * The raster/vector integrated approach of Euclidean distance can be reused here so that: |
| 249 | * the source points do not have to be in the output raster extent nor the cost raster extent (constraint 4) |
| 250 | * it is possible to to create a tiled raster coverage aligned to an existing reference raster (constraint 3) |
| 251 | * The scanning process can move randomly around the entire coverage. Pieces of rasters can be swapped in and out of memory in case of high resolution raster (constraint 1, constraints 5b, 5c, 5d). C implementation would be used for this situation. Use of a binary tree with an linked list at each node in the tree to efficiently hold cells with identical cumulative costs. |
| 252 | |
| 253 | |
| 254 | '''Cons:''' |
| 255 | * PL/pgSQL is not quite useful in initializations of vary large size arrays, any array update can be very slow (Constraint 1). Using array options in PL/pgsql can get very inefficient if the array size gets very large (constraint 5b,5c,5d). |
| 256 | |
| 257 | * There could be situation where source points are not within output raster nor current cost raster due to that cost raster or output raster might be tiled raster coverage (constraint 4). In that case, accumulatvie cost will be calcualted based upon the edge pixels to adjacent raster. |
| 258 | |
| 259 | |
| 260 | '''Future work:''' |
| 261 | Future work will be done to make it work with multiple cost rasters (constraint 7). |
| 262 | |
| 263 | [[BR]][[BR]] |
| 264 | ==== Tentative functions signatures: ==== |
| 265 | |
| 266 | ST_CostDistance(refrast raster,pixeltype text,costrast raster,sourceschema text,sourcetable text,sourcegeomcolumn text, double precision = -1); |
| 267 | |
| 268 | ST_CostDistance(width integer,height integer,rastulx float8,rastuly float8,rastscalex float8,rastscaley float8,rastskewx float8,rastskewy float8,rastsrid integer,rastndv float8,pixeltype text,costrast raster,sourceschema text,sourcetable text,sourcegeomcolumn text,double precision = -1); |