[GRASS-dev] lidar tools update in grass7

[Maris Nartiss]

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 <markus.metz.giswork at googlemail.com>:
> 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_bepts at 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_bepts at 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_bepts at 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_bepts at 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_bepts at 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
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>