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

[Markus GRASS]

Michael Perdue wrote:
>
>
> I read through the one of the papers today  ( M. A. Brovelli , M.
> Cannata and U. M. Longoni, 2002.  Managing and processing LIDAR data
> within GRASS,  Proceedings of the  / Open source GIS - GRASS users
> conference 2002)  and the authors recommended a step value or 3 to 4
> time the average point spacing of the data set. So 4m sen & see values
> seems appropriate for a data set that has an average coverage of 1
> return/m^2. Unfortunately, the authors didn't really explain why it
> should be 3-4 times and not say 10. I can only guess that a smaller
> step size would produce finer details in the interpolation and better
> feature isolation for the classification./
>
> There definitely seems to be something funky going on between the
> spline step size and the division of the region into subregion. I ran
> tests using v.lidar.edgedetection on tiles of 500x500m, 800x800m ,
> 801x801m and 1000x1000m. Times for each run
> were 1m54.065s, 6m35.420s, 22m16.708s & 68m25.265s respectively. There
> was a ~3 fold increase in processing time when I grew the data set by
> 1m from  (800m)^2 (what I understand to be the maximum size of the
> region before it is broken up into subregions) to (801m)^2 and
> it tripled again when I jumped to (1000m)^2. I also recompiled grass
> with NSPLX_MAX and NSPLY_MAX set to 1500 instead of the current 200
> and the time to process a (1000m)^2 tile dropped from 68 minutes to 12
> minutes.
>
> My understanding is that a region is broken up into smaller subregions
> to avoid memory limitations while processing. I can't see any reason
> why the division of the region into more smaller subregions should
> increase the resolution of those subregions. I'm far from an expert on
> these programs, and I'm not skilled enough to read through the code
> and know what it is doing, but if I understand you correctly, your
> arguments make sense to me. If you're kind enough to share your
> changes I'll apply them and do some more testing.
I didn't get to look into that in more detail, stopped at
edgedetection.c without getting a working solution. The general idea is
either to use the current geographic region resolution or to use point
density for estimated resolution, then use sen and see as step size. I
can not possibly say if that makes sense, I have to read the references,
but will not get to it soon. How about contacting the original authors?

Markus M