[GRASS-dev] lidar tools update in grass7

Hamish hamish_b at yahoo.com
Sun Feb 7 23:18:18 EST 2010


Markus Metz wrote:
> The core of the lidar tools is the lidarlib, that is AFAICT
> robust and working. Bugs are most likely in modules, so I'll try
> to add comments there. I have reorganized the code for v.surf.bspline
> in the hope that it is now easier to read.

Slightly off-topic, but while we are thinking about this code ...

A while back I did some crude profiling of the v.lidar tools and found
that it was spending lots and lots of time in the Tcholetsky decomposition
loop (3-for loops deep).

It seemed like a good & simple test case for using OpenMP to multi-thread
it, but I got stuck with it segfaulting. AFAIR the problem was that OpenMP
wanted you to malloc the entire thing before starting, and this could
get big.

if it interests you, see the attached patch and
  https://trac.osgeo.org/grass/ticket/657
  http://lists.osgeo.org/pipermail/grass-dev/2009-June/044709.html
  http://lists.osgeo.org/pipermail/grass-dev/2009-June/044705.html
  http://grass.osgeo.org/wiki/OpenMP


> I forgot to mention, there is a problem with sqlite, it is much slower
> than dbf, no idea if this is a problem of my system or of the grass 
> sqlite driver or of the way auxiliary tables are accessed by the lidar
> tools.

that sounds vaguely familiar, but as a general thing not necessarily
to do with v.lidar. probably something about it in the archives?


Hamish



      
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openmp_lidarlib_trunk.patch
Type: text/x-diff
Size: 1897 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20100207/a0bdb743/openmp_lidarlib_trunk.bin


More information about the grass-dev mailing list