Changes between Version 9 and Version 10 of PostGIS_Raster_SoC_Idea_2012/Distance_Analysis_Tools/document


Ignore:
Timestamp:
Jul 12, 2012, 10:39:30 PM (12 years ago)
Author:
qliu
Comment:

—

Legend:

Unmodified
Added
Removed
Modified

  • PostGIS_Raster_SoC_Idea_2012/Distance_Analysis_Tools/document

    v9 v10  
    99=== Objectives ===
    1010
    11 We want to develop a raster/vector integrated approach to generate a distance raster coverage (optionnaly a tiled coverage) from a point coverage (could also be lines or polygons coverage) with some raster specifications, representing the euclidean distance to those points (lines or polygons).
     11We want to develop a raster/vector integrated approach to generate a distance raster coverage (optionally a tiled coverage) from a point coverage (could also be lines or polygons coverage) with some raster specifications, representing the Euclidean distance to those points (lines or polygons).
    1212
    1313This approach should be reusable and opening the way to further implementation of interpolation raster, since the distance raster is a specific and simpler case of an interpolation raster, in terms of storing the value associated with the nearest point(s) instead of distance to it.
    … …  
    1616=== Constraints ===
    1717
    18 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.[[BR]]
    19 2.      The desired raster is specified with parameters or by referencing an existing raster.[[BR]]
    20 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.[[BR]]
    21 4.      Source geometries might be outside the extent of the desired raster.[[BR]]
    22 5.      The approach should work well in a number of situations:
     18 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.
     19 2.     The desired raster is specified with parameters or by referencing an existing raster.
     20 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.
     21 4.     Source geometries might be outside the extent of the desired raster.
     22 5.     The approach should work well in a number of situations:
    2323  a.    small number of sources vs low resolution raster
    2424  b.    small number of sources vs high resolution raster
    2525  c.    large number of sources vs low resolution
    2626  d.    large number of sources vs high resolution Large raster coverage
    27 6.      The user can specify a maximum distance to the source. When the source is too far from the geometry it gets assigned a nodata value.[[BR]]
    28 7.      We want the implementation to be generic enough to be reused to implement more general interpolation methods like nearest neighbor, IDW, spline or kriging. Otherwise we want it to be generic enough to be reused to implement more general cost distance methods.[[BR]]
     27 6.     The user can specify a maximum distance to the source. When the source is too far from the geometry it gets assigned a nodata value.
     28 7.     We want the implementation to be generic enough to be reused to implement more general interpolation methods like nearest neighbor, IDW, spline or kriging. Otherwise we want it to be generic enough to be reused to implement more general cost distance methods.
    2929
    3030=== Different Envisioned Approaches ===