Changes between Version 48 and Version 49 of PostGIS_Raster_SoC_Idea_2012/Distance_Analysis_Tools
- Timestamp:
- 06/22/12 12:02:25 (13 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
TabularUnified PostGIS_Raster_SoC_Idea_2012/Distance_Analysis_Tools
v48 v49 364 364 * Algorithms: 365 365 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. 366 {{{ 367 #!html 368 <div style='background-color: #F4F4F4; border: 1px solid gray; width:800px; padding:10px' > 369 <br> 370 <b>Comment from Mentor:</b> 371 <p> 372 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? 373 </p> 374 <br> 375 </div> 376 }}} 366 377 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. 367 378 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''' 372 383 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. 384 {{{ 385 #!html 386 <div style='background-color: #F4F4F4; border: 1px solid gray; width:800px; padding:10px' > 387 <br> 388 <b>Comment from Mentor:</b> 389 <p> 390 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. 391 </p> 392 <br> 393 </div> 394 }}} 373 395 * Issues to be considered: 374 396 * 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> 414 436 <br> 415 >> From: Pierre<br>437 Pierre Wrote:<br> 416 438 >> I want also a kind of approach to the problem of billions of points. Does<br> 417 439 >>the knn indexing help us in quickly identifying what is the nearest point to the<br> 418 440 >>pixel without rescanning all the point for every pixels.<br> 419 > From: Qing<br>441 Qing Wrote:<br> 420 442 > Yes, KNN index will definitely help us to identify the nearest point to the pixel.<br> 421 443 > With the capability of PostGIS 2.0 to return sorted results from a GiST index, we<br>