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 _______________________________________________ grass-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-user
