[GRASS-user] v.lidar.edgedetection very slow

Markus GRASS markus.metz.giswork at googlemail.com
Sat Jun 20 03:56:34 EDT 2009

Hamish wrote:
>> Some of the nested for(;;) loops could be improved by
>> adjusting start and end values. Maybe the attached patch for
>> vector/lidar/lidarlib/TcholBand.c helps. No warranty!
> tested with v.lidar.edgedetection, coor and dbf binary files identical
> before and after the patch. Hopefully that module touches all modified
> lib fns to make it a good test. Applied in trunk and devbr6. Sped things
> up by ~13% in my one test.
Did some more testing. The see and sen options have drastic influence on
speed, with larger values it completes in a minute, with default values
it takes hours (lidar points in North Carolina sample dataset with 10m
resolution in the current computational region).

If have not the faintest idea about the theory behind the edge detection
code, but something appears strange to me, it's the effect of the sen
and see options. These options are interpolation spline step values
(option description), apparently something like step size. The current
computational region will be subdivided into several overlapping
subregions (source code comment). For each subregion, bilinar
interpolation, T Cholesky Decomposition, bicubic interpolation and
another T Cholesky Decomposition is done, then point classification.
What I don't understand is why with smaller steps, i.e. more, smaller
subregions, the resolution of these subregions is increased and the
matrix becomes larger. That's causing the incredibly long running time
of the module. It should be the other way around, larger step values
cause larger subregions and larger matrices not smaller matrices.
Changing the code in main.c and edgedetection.c accordingly gives very
similar results to the original version, only that the time required is
near constant for different spline step values and always very short,
nothing like hours, just a minute or two. It would be nice to have some
hints in the manual how to calculate reasonable values for a given lidar
point set and current computational region.

I'm not attaching any patches because I'm not sure of the original
behaviour is intended or if my arguments make sense. Haven't read all
the references...

Markus M

More information about the grass-user mailing list