Changes between Version 48 and Version 49 of PostGIS_Raster_SoC_Idea_2012/Distance_Analysis_Tools

Timestamp:

Jun 22, 2012, 12:02:25 PM (12 years ago)

Author:

qliu

Comment:

—

PostGIS_Raster_SoC_Idea_2012/Distance_Analysis_Tools

@@ -364 +364 @@
  * Algorithms:
    a. Make an empty raster new_rast, using the same extent as the input vector point data source_point, set pixel value to NoData value.
+{{{
+#!html
+<div style='background-color: #F4F4F4; border: 1px solid gray; width:800px; padding:10px' >
+<br>
+<b>Comment from Mentor:</b>
+<p>
+I don't think this is a good idea as you would have no control on the alignment of the raster produced. I want to be able to control the dimensions and how the raster is georeferenced. I think your best friend here is ST_AsRaster() which allows passing a geometry and some raster properties and burns the geometry in the raster. Basically ST_AsDistanceRaster() should not be so different from ST_AsRaster(), the only difference is that instead of burning the geometry in the raster, we compute a distance to the geometry for each pixel. It is very possible in this case that the geometry will be outside the extent of the requester raster. Should we want this to work for lines and polygons?
+</p>
+<br>
+</div>
+}}}
    b. Utilize ST_SetValue(raster rast, geometry pt, double newvalue) function to designate source pixels in the resulting raster where vector source point(s) intersect(s) with the new raster.We want to assign “0” as new pixel value to pixels as source pixel(point) since the Euclidean distance from source to itself is zero.
    c. Calculate Euclidean distance from the center of source pixel(s) to each pixel in the raster:[[BR]]
@@ -371 +382 @@
      '''Need to consider scan algorithm in case of more than one point in the source data'''
    e. Utilize ST_MapAlgebraExpr() function to multiply resulting distance raster with pixel size to get the real geographic distance in the unit assigned in the georeferencing info.
+{{{
+#!html
+<div style='background-color: #F4F4F4; border: 1px solid gray; width:800px; padding:10px' >
+<br>
+<b>Comment from Mentor:</b>
+<p>
+You should avoid to do two passes to compute the final pixel values: one to compute the distance in pixel/cell and another to convert into the geographical distance.
+</p>
+<br>
+</div>
+}}}
  * Issues to be considered:
    * Scanning method in case of source point data containing more than one source point:
@@ -413 +435 @@
 I think with the knn index already built you could scan pixels only once assigning the distance to the closest point. and that would be fast even if there are millions. Is this correct?<br>
 <br>
->> From: Pierre<br>
+Pierre Wrote:<br>
 >>       I want also a kind of approach to the problem of billions of points. Does<br>
 >>the knn indexing help us in quickly identifying what is the nearest point to the<br>
 >>pixel without rescanning all the point  for every pixels.<br>
-> From: Qing<br>
+Qing Wrote:<br>
 > Yes, KNN index will definitely help us to identify the nearest point to the pixel.<br>
 > With the capability of PostGIS 2.0 to return sorted results from a GiST index, we<br>