Changes between Version 36 and Version 37 of PostGIS_Raster_SoC_Idea_2012/Distance_Analysis_Tools/document


Ignore:
Timestamp:
Aug 20, 2012, 8:21:01 AM (12 years ago)
Author:
qliu
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • PostGIS_Raster_SoC_Idea_2012/Distance_Analysis_Tools/document

    v36 v37  
    211211}}}
    212212
    213 
     213[[BR]][[BR]][[BR]][[BR]]
    214214== Creating a Cost-weighted Distance Raster in PostGIS Raster ==
    215215[[BR]][[BR]]
     
    217217
    218218We want to develop a raster/vector integrated approach to generate a cost-weighted distance raster coverage (optionally a tiled coverage) from a point coverage (could also be lines or polygons coverage) and one (could also be multiple) cost raster with some raster specifications, representing the least accumulative cost of traversing the cost surface between each cell and the source points.
    219 
     219[[BR]][[BR]]
    220220=== Constraints ===
    221221
    222222 1.     The source table of geometries (points, line or polygons) can contain one geometry or many (eventually millions). We want the method to scale well whatever the number of source geometry.
    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:
    227227  a.    small number of sources vs low resolution raster
    228228  b.    small number of sources vs high resolution raster
    229229  c.    large number of sources vs low resolution
    230230  d.    large number of sources vs high resolution Large raster coverage
    231 6.      The user can specify a maximum cost distance to the source. When the cost exceeds the maximum it gets assigned a nodata value.
    232 7.      There are multiple cost rasters, and could be in different geographic extents.
    233 
    234 
     231 6.     The user can specify a maximum cost distance to the source. When the cost exceeds the maximum it gets assigned a nodata value.
     232 7.     There are multiple cost rasters, and could be in different geographic extents.
     233
     234[[BR]][[BR]]
    235235=== Approach ===
    236236
     
    239239The algorithm utilizes the node/link representation for raster cells, in which each center of a cell is considered a node and each node is connected to its adjacent cells(neighbors) by multiple links. Every link has an impedance derived from the cost raster associated with the cells at each end of the link. The cost-weighted distance assigned to each cell represents the cost per unit distance for moving through the cell computed from the cell value in cost raster.
    240240
    241 For perpendicular direction link, the cost moving from cell1 to cell2 = (cost1 + cost2) / 2
    242     For diagonal direction link, the cost moving from cell1 to cell2 = sqrt(2)*(cost1+cost2)/2
     241 For perpendicular direction link, the cost moving from cell1 to cell2 = (cost1 + cost2) / 2
     242 For diagonal direction link, the cost moving from cell1 to cell2 = sqrt(2) * (cost1+cost2) / 2
     243
    243244The calculation begins with source points (polylines or polygons). The computing process grows in 8 directions from source points to the neighboring cells. Cells are put into a list. The cell with the lowest cumulative cost is selected from the list for computing costs to its neighboring cells. The neighbors are then put into the list while the originating cells are removed from the list. The scanning process continues until the list is empty.
    244245
    245246'''Pros:'''
    246247
    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:'''
     261Future work will be done to make it work with multiple cost rasters (constraint 7).
     262
     263[[BR]][[BR]]
     264==== Tentative functions signatures: ====
     265
     266ST_CostDistance(refrast raster,pixeltype text,costrast raster,sourceschema text,sourcetable text,sourcegeomcolumn text, double precision = -1);
     267
     268ST_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);