[GRASS-user] Re: [GRASS-dev] Some comments on the v.surf.icw add-on

Benjamin Ducke benjamin.ducke at oxfordarch.co.uk
Sat Jan 9 08:53:54 EST 2010

----- "Hamish" <hamish_b at 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


> > 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)!



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.

More information about the grass-user mailing list