r.fillnulls / v.surf.rst: use of segmax and npmin disarranged
|Reported by:||sbl||Owned by:|
After some speed-up r.fillnulls still feels quite slow on big rasters (http://trac.osgeo.org/grass/ticket/1938). On further investigation in particular the following waring message indicated some confusion in the npmin and segmax settings in r.fillnulls and/or v.surf.rst:
Interpolating 40 points[[BR]] (...)[[BR]] WARNING: There are less than 80 points for interpolation.[[BR]] No segmentation is necessary, to run the program faster set segmax=80 (see manual)
In r.fillnulls, if number of points is below 600, then both segmax and npmin are set to "pointsnumber". So, from r.fillnulls segmax was set to 40 (and not 80, like the warning message indicates...). Then I tested in v.surf.rst with a hole with 1033 existing data points on the edge with the following result: If I set segmax = 1033 npmin = 1033
I get the following Warning message:WARNING: There are less than 2066 points for interpolation.[[BR]] No segmentation is necessary, to run the program faster set segmax=2066 (see manual)
Interpolation is done within 6 seconds.
I get the same message if I set: segmax = 517 npmin = 1033 But now processing takes now 16 seconds...
The warning message above changes to
WARNING: There are less than 1034 points for interpolation.[[BR]] No segmentation is necessary, to run the program faster set segmax=1034 (see manual)
when I set:
segmax = 1033 npmin = 517 Strange that it is possible because in the GUI it says npmin has to be greater than segmax... But processing time is down on 6 secs again...
With: segmax = 1033 npmin = 516. I get the expected error message, that npmin has to greater than segmax.
Finally, I set segmax and npmin to the "default" in r.fillnulls for holes with pointnumber >= 600:
segmax = 100
npmin = 300 Now processing takes 55 seconds!!! This is especially confusing because during the tests with npmin = 1033 I got the following warning message in addition:
WARNING: The computation will last too long - lower npmin is suggested"
But actually, processing was nearly 10 times faster then with npmin=300!