> > Even cost along a straight line (or maybe a great circle?) is > computationally expensive, and in the general case would require > holding the entire cost map in memory. Less-general cases would have > to be implemented within the module, as the libraries wouldn't know > how the module intends to access the cost map. > > Also, many algorithms which have a concept of distance require that it > follows the conditions for a metric, i.e. for some metric d and all > points x, y, z: > > d(x,x) = 0 > d(x,y) >= 0 > d(x,y) = d(y,x) > d(x,z) <= d(x,y) + d(y,z) > > A distance calculated by integrating a cost map along a fixed path > could violate the fourth condition (transitivity). > > Other algorithms (e.g. r.grow.distance) require that distance > increases monotonically with both delta-x and delta-y, and the > proposed solution would violate that. >
Right, a general and simple solution for cost-based distance is not as straight forward as I thought it might be. I will think about how this could be done for individual modules instead -- and which modules would actually benefit significantly from cost distances. Thanks for all the feedback. Ben > -- > Glynn Clements <[email protected]> > _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
