[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 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. So. if it is an API break
 depends on how much you care about invalid points in your data. The two
 people on GIS SE didn't know about point validity and they actually want
 all the points. I personally wouldn't know about validity if I didn't know
 about the function call in the source code. (This is a call for anybody
 who would be negatively affected by the change.)

 Moreover, we don't promise validity G7:r.in.lidar filtering in the manual,
 so the claim can be that invalid point filtering not behavior one should
 rely upon.

 > ...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).

 The mess around it suggests that there is no clearly defined validity.
 When validity itself is not clearly defined in standard and it changes for
 individual properties with different format versions, what the library is
 actually doing and how it behaves (will behave) with different format
 versions? This seems to me like a buggy feature which should be disabled.


 > * Add a flag to ignore validity checks

 I still think that this change in the API is worth it. It might be even a
 fix. So, I'm still for the opposite flag.

 > * Understand why scan angle 0 is declared invalid ... and solve that

 We can do some checks ourselves which would likely change the results/API
 as well. But I don't know what to study anyway and if it is even worth it
 as the practice may be really different from the theory here.

 > * 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).

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