Hello again, Thanks for testing the modules. Apparently, the errors are only related to the date stamp at the bottom of the manual pages and therefore aren't affecting the functioning of the module.
> It seemed like all ran faster, but maybe that was my imagination. The > backlinked and non-backlinked paths made on a cost surface from running > r.cost on a slope map are very similar to each other. I'm surprised it ran faster, since it is actually doing more in the new versions. However, to a certain extent the speed depends on the paths that it finds so I think a straighter path would be calculated faster than one with lots of curves. > > The backlinked and non-backlinked paths made on a cost surface using r.walk > are very different from each other, though the non-backlinked path on an > r.walk surface was very similar to the backlinked and non-backlinked paths > on an r.cost surface. The backlinked path looked a little odd, transecting > rugged terrain in almost a straight line. In fact the backlinked paths from > r.walk are nearly straight lines. Is this a reasonable result? The path in the middle of your r.walk backlink map seems to cross rugged terrain but the ones in the the NW and SE corners seems to be traversing slopes quite well. I should emphasize that the added functionality does not alter the way the cost algorithm calculates paths, rather it only makes sure that the path is accurately recorded. > > One fairly serious problem is that the backlinked paths are discontinuous, > with lots of gaps; the non-backlinked paths are continuous without gaps. I assume you used the "knight's move" option? I agree the discontinuous paths may cause some problems, especially when trying to vectorize the paths. However, the gaps are legitimate in the sense that they were created by the knight's move which makes small jumps for the sake of more accurate directionality (you can see this if you look closely at drain_backlinkvsnobacklink.png). Unlike the old r.drain function, the updated r.drain only draws the cells actually used in the cost algorithm. I'm not sure how we can overcome the vectorization problem though, especially since you need vectorization to determine the overall distance traveled. > > I've posted screenshots of the tests at: > http://www.public.asu.edu/~cmbarton/files/grass_cost/ Thanks for the tests and the screenshots. -Colin _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
