| | 519 | |
| | 520 | |
| | 521 | {{{ |
| | 522 | #!html |
| | 523 | <div style='background-color: #F4F4F4; border: 1px solid gray; width:800px; padding:10px' > |
| | 524 | <br> |
| | 525 | <b>Comment from Mentor:</b> |
| | 526 | <p> |
| | 527 | I find the constraints are not really well stated as a first part of the document. Could you list those constraints, right here, so we agree on them?<br> |
| | 528 | Also:<br> |
| | 529 | To produce a distance raster we need to know which point is the nearest from the pixel centroid.<br> |
| | 530 | To produce a more generic interpolation surface (as we would like to be able to do), which points do we need to know? Only the three nearest points? The three nearest points forming a triangle encompassing the pixel centroid? More points?<br> |
| | 531 | Maybe those two problems can resume to one if we would build a Delauney triangulation with the point before trying to produce any surface. So the process would be two steps: 1) Build a Delauney surface 2) Compute some metric for each pixel centroid.<br> |
| | 532 | </p> |
| | 533 | <hr/> |
| | 534 | <b>Comment from PostGIS-Devel:</b> |
| | 535 | <p> |
| | 536 | <a ref="mailto:pramsey@opengeo.org ">Paul Ramsey</a> Wrote: |
| | 537 | On the algorithm side, the first case is "OK", though of limited value |
| | 538 | I would imagine (most use cases will involve multiple inputs, and not |
| | 539 | just points). |
| | 540 | <br> |
| | 541 | On the multiple inputs side, you really have to grapple with the fact |
| | 542 | that people will be starting from many different kinds of geometry, so |
| | 543 | your input is best not thought of as "a multipoint" but "a grid of |
| | 544 | starting locations", which could be derived from any kind of geometry. |
| | 545 | <br> |
| | 546 | I also note that the distance grid is actually just a specialization |
| | 547 | of a generalized cost surface, where grid values are calculated as |
| | 548 | using input of a starting point grid and a friction grid. In the case |
| | 549 | of the distance grid you are just assuming a uniform friction grid, |
| | 550 | but for maximum utility you might want to consider doing a cost |
| | 551 | surface instead. |
| | 552 | <br> |
| | 553 | The algorithm is much less parallelizable, because you have to work |
| | 554 | out from the start points, however it's a nice little recursive |
| | 555 | function. From each start point you calculate the cost of the |
| | 556 | neighbors as a product of the friction of the neighbor and the |
| | 557 | distance to the neighbor (one unit in left-right-up-down directions, |
| | 558 | root-2 units in the diagonals). If a cell already has a value, skip |
| | 559 | it. You can use a threshold as in your algorithm as a stopping |
| | 560 | condition. |
| | 561 | <br> |
| | 562 | With a friction grid of 1, this nets out to the distance grid. |
| | 563 | <br> |
| | 564 | Start only from points seems fundamentally limiting for no good |
| | 565 | reason. The added "precision" you get by working directly against the |
| | 566 | points seems pretty pointless for most grids. You'll get a lot of |
| | 567 | users forced to convert their input geometries into point sets before |
| | 568 | starting, and then their question will be "why is it slow" and you'll |
| | 569 | say "because you have too many points, then them" and they'll say |
| | 570 | "how" and you'll say "snap them to a grid basis" and at that point |
| | 571 | they might as well have rasterized anyways. |
| | 572 | <br> |
| | 573 | I still think a generic cost calculator would be more useful than a |
| | 574 | single-purpose distance calculator. |
| | 575 | </p> |
| | 576 | <br> |
| | 577 | </div> |
| | 578 | }}} |
| | 579 | |
| | 580 | ---- |
| | 581 | {{{ |
| | 582 | #!html |
| | 583 | <div style='float: right; width:100px;'> |
| | 584 | <a href="#PostGISRasterSoCIdea2012-DistanceAnalysisToolsforPostGISRaster"> <img src="https://lh3.googleusercontent.com/-YR7gUJULQrM/T8nEPQ-AtzI/AAAAAAAAA1M/T_6vRjE8E4Q/s40/scroll_to_top_icon_40x40.png"><br>back to top</a> |
| | 585 | </div> |
| | 586 | }}} |
| | 587 | |
| | 588 | == Week 5 Report == |
| | 589 | |
| | 590 | '''What did you get done this week?''' |
| | 591 | * Revised proposal for creating distance surface based on the comments and discussions with Pierre. |
| | 592 | |
| | 593 | ''' What do you plan on doing next week?''' |
| | 594 | * Revise the proposal from last week according to the feedback from the mentor |
| | 595 | |
| | 596 | '''Are you blocked on anything?''' |
| | 597 | * Pierre's comments and feedbacks are very helpful in guiding me through the problems I've encountered. |
