Changes between Version 56 and Version 57 of PostGIS_Raster_SoC_Idea_2012/Distance_Analysis_Tools


Ignore:
Timestamp:
Jun 29, 2012, 9:15:42 PM (12 years ago)
Author:
qliu
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • PostGIS_Raster_SoC_Idea_2012/Distance_Analysis_Tools

    v56 v57  
    611611
    612612'''What did you get done this week?'''
    613  *
    614  *
     613 * Discussed with mentor,
     614 * Came up with a preliminary approach briefly discribed as below:
     615
     616Based on the discussion, I think the way that ST_MapAlgebraFct() works could be the way for computing Euclidean distance and interpolation in terms of creating a new raster based on a SQL function. And the function should be already set like returning the hypotenuse value for Euclidean distance and more complicated functions for interpolation according to different interpolation methods. The problem is to determine to which pixel (the nearest neighbour) the function (formula) should be applied for the current pixel. As we agreed we want to use KNN indexing for this problem.
     617
     618I come up with an approach which I think should work for a single raster situation where the source points are within the geographic extent of the result raster:
     619First create an empty raster based on the source data (a table of points) as the "container" for the resulted Euclidean distance raster. The raster will have the same georeference as the source data points; The SQL function could be like:
     620
     621CREATE FUNCTION euclidean_fct(pixel float, pos integer[], source
     622geometry, variadic args text[])
     623RETURNS float
     624AS $$
     625BEGIN
     626       SELECT ST_Distance(ST_Point(pos), source) as eucliean_dis
     627       ORDER BY $1 <-> $2
     628       LIMIT 1;
     629       Return euclidean_dis;
     630END;
     631$$
     632LANGUAGE 'plpgsql';
     633
     634Then we can just UPDATE new_rast SET rast = ST_MapAlgebraFct(rast,NULL,'euclidean_fct(float,integer[],geometry,text[])'::regprocedure);
     635
     636{{{
     637#!html
     638<div style='background-color: #F4F4F4; border: 1px solid gray; width:800px; padding:10px' >
     639<br>
     640<b>Comments from the Mentor:</b>
     641<p>
     642A 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?
     643</p>
     644<br>
     645</div>
     646}}}
     647
     648Not sure whether I can pass in a geometry in the function above. The ways that raster and point geometry works are logically pretty similar. Like we can make point geometry from a given coordinate (x,y) pair, pixels in a raster are also organized in a relative coordinate system with the defined height and width of the
     649raster in which the (x,y) pair of coordinate indicates the relative position of this pixel in the raster.
     650My thoughts are when we create the result euclidean raster from the source table of points with the same extent, the points geometry can be then projected into this relative coordinate system of the raster, so that the position of a pixel and the relatively projected coordinate of a point geometry could be exchangeable with or equivalent to each other.
     651
     652But 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.
     653
    615654
    616655''' What do you plan on doing next week?'''
    617  *
    618  *
    619 
    620 '''Are you blocked on anything?'''
    621  *
    622  *
     656{{{
     657#!html
     658<div style='background-color: #F4F4F4; border: 1px solid gray; width:800px; padding:10px' >
     659<br>
     660<b>Commented and Suggested by the Mentor:</b>
     661<p>
     662Write a  document summarizing the approach above including, in order:<br>
     6631- Objective<br>
     6642-The list of constraints<br>
     6653-At least three approaches (converting point to raster, creating a TIN first, the approach described here) and the pros and cons for each approaches in relation with the constraints<br>
     6664-Your choice of approach and the reason why<br>
     6675-A series of function signature offering flexibility to the user<br>
     668</p>
     669<br>
     670</div>
     671}}}