[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 [comment:2 wenzeslaus]:
 > Replying to [comment:1 mlennert]:
 > > ...the general rule of no API changes within the same major number
 releases...
 >
 > It is changing behavior because the output might be different. However,
 it does not break scripts in general, although you might just get more
 points or invalid points depending on your data.

 IMHO, the output counts as well, not only the fact that scripts might
 break.

 But as you say, in light of the very unclear definition of these points,
 one could consider the silent suppression of points a bug, and so your
 flag proposal a bug fix.

 So, I would say: go ahead with your proposal (flag to filter non-valid
 points), but maybe the module should output an information message about
 this change.


 > > * In the long run: determine whether libLAS is still a good choice...
 >
 > Right. I think PDAL (which BTW doesn't have any validity check) is a
 good replacement, but I wasn't able to touch it for some time (#2732).

 Yes, I guess PDAL would be a better choice than LASlib... It would be
 great if there were a C-API to PDAL. I would be a bit hesitant to
 introduce C++ dependence in what would probably be considered a core
 module.

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