613 | | * |
614 | | * |
| 613 | * Discussed with mentor, |
| 614 | * Came up with a preliminary approach briefly discribed as below: |
| 615 | |
| 616 | Based 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 | |
| 618 | I 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: |
| 619 | First 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 | |
| 621 | CREATE FUNCTION euclidean_fct(pixel float, pos integer[], source |
| 622 | geometry, variadic args text[]) |
| 623 | RETURNS float |
| 624 | AS $$ |
| 625 | BEGIN |
| 626 | SELECT ST_Distance(ST_Point(pos), source) as eucliean_dis |
| 627 | ORDER BY $1 <-> $2 |
| 628 | LIMIT 1; |
| 629 | Return euclidean_dis; |
| 630 | END; |
| 631 | $$ |
| 632 | LANGUAGE 'plpgsql'; |
| 633 | |
| 634 | Then 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> |
| 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? |
| 643 | </p> |
| 644 | <br> |
| 645 | </div> |
| 646 | }}} |
| 647 | |
| 648 | Not 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 |
| 649 | raster in which the (x,y) pair of coordinate indicates the relative position of this pixel in the raster. |
| 650 | My 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 | |
| 652 | But 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 | |
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> |
| 662 | Write a document summarizing the approach above including, in order:<br> |
| 663 | 1- Objective<br> |
| 664 | 2-The list of constraints<br> |
| 665 | 3-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> |
| 666 | 4-Your choice of approach and the reason why<br> |
| 667 | 5-A series of function signature offering flexibility to the user<br> |
| 668 | </p> |
| 669 | <br> |
| 670 | </div> |
| 671 | }}} |