[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
> 

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.



More information about the grass-user mailing list