[GRASS-dev] lidar tools update in grass7

[Markus Metz]

Maris Nartiss wrote:
> Horay! Good job!
> Still could You, please, take a look at this issue:
> http://trac.osgeo.org/grass/ticket/96
>   
The column option works now and the module no longer sits there and does 
nothing, it reports now progress, and is faster, particularly for 
bicubic interpolation. I would recommend backporting all changes after 
some more testing because some of the lidar tools are not working 
properly in grass 6.x.

In ticket #96, the command

v.surf.bspline input=precip_30ynormals rast=precip_30ynormals_surf 
column=annual layer=1 sin=1000 sie=1000

is ok for testing, nicer results are obtained with

v.surf.bspline input=precip_30ynormals rast=precip_30ynormals_surf 
type=bicubic column=annual layer=1 sin=4.0e+4 sie=4.0e+4

> 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? 
I'll try my best. I think I understand the code, but I don't really 
understand that Tcholetsky thing (which I did not touch), so I can't add 
comments there.
> 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.
>   
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.

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.

Markus M
> 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
>>
>>     
>
>