----- "Hamish" <hamish_b@yahoo.com> wrote:
how about editing in some small 1 pixel land bridges eg from norway
to
denmark and the tip of italy to..lots of places. with a the relative
cost/risk of sailing to the other side? seems like a lot of walking
could be avoided by a small boat trip every now and then.
or just apply some high cost value to water cells instead of NULL.
?
Yup, that's what we did 
The cost surface includes cheap costs in the coastal waters
within visible distance from the mainland. Also, we allowed
for cheap travel along the main rivers.
I ran the same calculations with euclidean distances and there
is a reasonable difference.
> If you could add FP support
done
Excellent!
> and an option to set the number of input points, that would be
> superb.I don't think I can set the number of input points; or rather I could
but it really wouldn't save you any time as you have to do the main
calculation before you can answer the question of what the most local
points are. What I can do is add a max_cost= option to feed to r.cost
which will save time. Beyond that cost (units: number of cells) the
weighting would be set to zero. This will incur at least 1 (maybe
more)
additional r.mapcalc step if the option is used, but that's still
probably
faster than waiting for r.cost to search to the ends of the earth
(guessing, only testing will tell and it probably depends on the
relative
speed of your CPU vs. hard drive).
Right, I was assuming the n points option in most IDW implementations
is there because it saves time with a lot of input points. But that would
only be the case if the n closest points can be found efficiently, which
as you say, is hard with a cost surface.
Max cost would be great in combination with an option to set each
output cell to NULL which is located > maxcost from any input point.
luckily there is a simple polynomial which fits my hand calculated
correction almost perfectly. (IIRC the uncorrected versions lead to
such tiny numbers that all of the floating point precision was tied
up in maintaining fidelity for them which was degrading the of the
precision of the useful data range)
That is lucky indeed (and probably good prove that your correction
factor was sound in the first place)!
Cheers,
Ben
------
Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information.