[GRASS-dev] [GRASS GIS] #3038: Decide if validity check in r.in.lidar should be an additional filter or a filter enabled by default

[GRASS GIS]

#3038: Decide if validity check in r.in.lidar should be an additional filter or a
filter enabled by default
-------------------------+-------------------------------------------------
  Reporter:  wenzeslaus  |      Owner:  grass-dev@…
      Type:  task        |     Status:  new
  Priority:  normal      |  Milestone:  7.2.0
 Component:  Raster      |    Version:  svn-trunk
Resolution:              |   Keywords:  r.in.lidar, r3.in.lidar,
       CPU:              |  v.in.lidar, libLAS, PDAL
  Unspecified            |   Platform:  Unspecified
-------------------------+-------------------------------------------------

Comment (by mlennert):

 Replying to [ticket:3038 wenzeslaus]:
 > Based on discussion on [http://gis.stackexchange.com/a/187559/10759 GIS
 SE] I wonder if we should make the filtering of lidar points based on
 validity in r.in.lidar, r3.in.lidar, and v.in.lidar optional.

 [...]

 > I've prepared a patch which turns the validity check into an additional
 filter which needs to be explicitly enabled if user wants it. It also
 removes validity check from scanning mode because no other filters are
 applied at that point. ''This changes the current behavior, so the
 question is if it is acceptable.''
 >
 > The alternative is to switch the logic in the patch to disable the
 filter if requested by user but have it on by default (i.e. current
 behavior by default).

 I think that in line with the general rule of no API changes within the
 same major number releases, the second option sounds better.

 However, looking at the last comment in the SE exchange, it seems that
 points are also declared invalid if the no scan angle is stored at all,
 i.e. there are two different kinds of invalidity: those which are based on
 a too large angle (and liblas seems to be quite restrictive, limiting this
 to -90 - 90 - whereas more recent [http://www.asprs.org/wp-
 content/uploads/2010/12/LAS_1_4_r13.pdf LAS specifications] allow -180 -
 180).

 So, I think we should:

 * Add a flag to ignore validity checks
 * Understand why scan angle 0 is declared invalid (if what Mihnea says on
 SE is true) and solve that
 * In the long run: determine whether laslib is still a good choice,
 knowing that it seems to have stalled in development ("libLAS is in a
 rather dormant period" as declared in the [http://www.liblas.org/faq.html
 FAQ])

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/3038#comment:1>
GRASS GIS <https://grass.osgeo.org>