#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 Keywords: r.in.lidar, r3.in.lidar, | CPU: Unspecified v.in.lidar, libLAS, PDAL | Platform: Unspecified | -------------------------------------------------+------------------------- 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.
For us validity is defined by whatever `LASPoint_IsValid(LAS_point)` considers valid. [http://www.liblas.org/utilities/las2las.html libLAS documentation says]: {{{ removes invalid (according to the ASPRS LAS file format specification) points. This switch should only be required in a few special circumstances. Points that might be invalid include those with larger-than-required scan angles. }}} ASPRS specification mentions validity of angles and also some numbers but otherwise I was not able to find clear information about valid and invalid points. PDAL does not have any concept like this and either all points are valid or application itself must decide what is valid. [https://lists.osgeo.org/pipermail/pdal/2015-September/000672.html Andrew Bell about PDAL on PDAL mailing list] (see also [http://www.pdal.io/tutorial/liblas_to_pdal.html#point-validity migration guide]): {{{ Point validity: there is no such concept }}} 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). -- Ticket URL: <https://trac.osgeo.org/grass/ticket/3038> GRASS GIS <https://grass.osgeo.org> _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev