On 01/03/12 20:02, Benjamin Ducke wrote:
I believe we are thinking in different directions here. My idea was not about _least_ cost paths, but about replacing straight-line distance measurements with cost-based distances -- for more realism when modelling physical processes.
Yes, but how to define the distance if not by finding the least-cost path. As soon as you do not use straight-line distance anymore, you have to decide of which path you want to calculate the distance, and in order to make this decision, you generally use the least-cost path.
What I was thinking about was to have just one CONST raster that encodes the cost of moving through each of its cells (in all directions in the simple isotropic case). All GRASS modules that use fixed neighborhoods or flexible search radii would then measure the distance between two points by accumulating the costs in the cells on the straight line between the two points.
So what you actually mean is somehow weight the distance by costs that can be found along the straigh-line path.
Suppose the user has created a COST raster with "1" representing "no additional cost" and "2" representing "doubled cost for crossing steep terrain". Then if he/she specified 100 m as e.g. the search radius for a KDE, the maximum search distance will in some extreme cases already be reached after approximately 50 m, because those 50 cost as much as 100 m on flat terrain. That would make the kernel's shape flexible and adjusted to the real terrain, instead of a fixed circle. The same idea translates 1:1 to IDW, r.neighbors, etc.
Well, in IDW if you decide to use the 12 "nearest" points, how would you decide this ? Maybe point A is "further" in terms of costs along a straight line than B, but if you use the least-cost path A might still be "closer"...
Moritz _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
