Horay! Good job! Still could You, please, take a look at this issue: http://trac.osgeo.org/grass/ticket/96 Also while You understand that code, please, could You add some commets to more tricky places in code to make code maintenance more easy for not-so-die-hard coders? Some things in GRASS lidar tools are really cool and advanced and thus not so easy to understand without carefull code review for casual bugfixers.
Thanks! Maris. 2010/2/5, Markus Metz <[email protected]>: > details on r40831: > > Performance has been increased for all modules by reducing the default > segment size, interpolation settings are not affected. Previously, the > modules seemed to be optimized for settings where only one segment was > needed. As soon as several segments where needed, processing time > increased drastically. Fixed for all modules, now optimized for larger > datasets. > > Sometimes interpolation settings were modified for the last row and > column segments, i.e. for these segments different interpolation > settings were used than for the other segments. The same spline step > values are now used for all segments. > > All modules have a new flag to estimate point density and mean distance > between points. This mean distance is the minimum spline step, according > to the documentation recommended spline steps are 2 to 4 times the mean > distance, depending on the module. > > All modules now create a proper name for the auxiliar table, sometimes a > name was created but a different one was used or a fully qualified name > with @ was used: illegal table name. > Several modules had memory leaks when accessing the auxiliar table, all > are fixed. > > v.lidar.edgedetection assigned category 0 instead of 3 to unknown points > (neither edge nor terrain), fixed. There was a bad memory leak in > v.lidar.edgedetection, fixed. > > v.outlier could not properly detect outliers if several segments were > needed, the points falling into the overlapping zones were not properly > updated (uninitialized variable used). > > v.surf.bspline no longer produces artifacts along region boundaries and > is now optimized for larger datasets. AFAICT it did not properly work if > the region had to be subdivided into several segments, it was restricted > to one segment. > > > test environment was nc_spm_08 > g.region vect=elev_lid792_be...@permanent res=1 > north: 221230 > south: 219580 > west: 637740 > east: 639530 > nsres: 1 > ewres: 1 > rows: 1650 > cols: 1790 > cells: 2953500 > > e.g. for grass64 > v.outlier --o --v input=elev_lid792_be...@permanent > output=elev_lid792_bepts_nooutliers64 > outlier=elev_lid792_bepts_outliers64 soe=5 son=5 thres_o=0.1 > and grass7 > v.outlier --o --v input=elev_lid792_be...@permanent > output=elev_lid792_bepts_nooutliers outlier=elev_lid792_bepts_outliers > soe=5 son=5 thres_o=0.1 > these settings will detect more outliers than are probably there, they > are for illustration of the artefacts. > > obvious artefacts in elev_lid792_bepts_outliers64 > > or in grass64 > v.surf.bspline --o --v input=elev_lid792_be...@permanent > raster=elev_lid792_rast64 sie=5 sin=5 type=bicubic lambda_i=0.1 > vs. grass7 > v.surf.bspline --o --v input=elev_lid792_be...@permanent > raster=elev_lid792_rast sie=5 sin=5 type=bicubic lambda_i=0.1 > > no more artefacts along the region boundaries and faster > > > _______________________________________________ > grass-dev mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/grass-dev > _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
