Changes between Version 58 and Version 59 of PostGIS_Raster_SoC_Idea_2012/Distance_Analysis_Tools


Ignore:
Timestamp:
Jul 1, 2012, 10:04:34 PM (12 years ago)
Author:
qliu
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • PostGIS_Raster_SoC_Idea_2012/Distance_Analysis_Tools

    v58 v59  
    640640<b>Comments from the Mentor:</b>
    641641<p>
    642 A general question in SQL is "How to iterate/compute a value for each pixel of a given raster computing a value based on a table of point?" Can you answer this question?
     642Why would the point have to be in the raster extent if what you pass to the custom function is the name of a geometry table (or view)?<br>
     643You don't pass a raster representing the point. How would you do that if you have many point and this is not in accordance with the idea of not converting points to raster.<br>
     644You pass a raster description based on parameter (similar to ST_AsRaster) or an existing raster and the name of a table (with the schema) and a geometry column (much like in ST_Count but passing a geometry column instead of a raster column) containing the points you want to compute the distance from for every pixels. Those points do not have to be in the raster extent and there can be as many as you want since you will be using the KNN index to find the nearest one.<br>
     645Generally you won't want to UPDATE an existing raster but rather create a new one based on an existing raster or even better an existing raster coverage. More something like:<br><br>
     646CREATE TABLE distcoverage AS
     647SELECT rid, ST_MapalgebraFct(rast, 'euclidean_fct(list of parameters including the table name and column name of the geometry table)'::regprocedure) rast
     648FROM myexistingcoveragetable<br><br>
     649We should afet encapsulate the ST_Mapalgebra function with a name and parameter list corresponding to a series of ST_EucledianDistance functions (some taking raster creation parameter, some taking a reference raster).
    643650</p>
    644651<br>
     
    652659But there will be situation where the source data is like billions of points and the extent would be too large to create a single raster (and the computation will be very inefficient). Then we will have to consider approaches for a tiled raster as the resulted Euclidean surface for the input source.
    653660
     661{{{
     662#!html
     663<div style='background-color: #F4F4F4; border: 1px solid gray; width:800px; padding:10px' >
     664<br>
     665<b>Comments from the Mentor:</b>
     666<p>
     667So the trick is to pass a geometry table name instead. That solve the issue of the point having to be in the raster extent (they don't have to). that also make it possible to create a tiled raster coverage perfectly aligned to an existing one...<br>
     668That approach can be reused to compute interpolation. But is not the way to go for cost distance which is more complicated.
     669</p>
     670<br>
     671</div>
     672}}}
    654673
    655674''' What do you plan on doing next week?'''