[GRASS-dev] Add a cost distance measure to GRASS GIS lib

[Moritz Lennert]

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