Opened 13 years ago
Closed 11 years ago
#1480 closed enhancement (fixed)
v.outlier - distinguish positive and negative outlier filtering from lidar point clouds
Reported by: | sbl | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | 7.0.0 |
Component: | Vector | Version: | unspecified |
Keywords: | review | Cc: | sbl |
CPU: | All | Platform: | All |
Description
In forest areas LIDAR returns usually both: signals from tree-tops (canopy) and from the ground as well. Unfortunately v.outlier (as it is today) filters positive and negative outliers at the same time, because it filters based on the absolute value of deviation from an interpolated surface. In forest areas, this appoarch affects both ground- and canopy-returns (meaning that very often both are being removed).
Usually a local minimum filtering is applied for removing vegetation returns from LIDAR point clouds (see: http://www2.geog.ucl.ac.uk/~plewis/lidarforvegetation/UCL-ALS-Lidar_for_Vegetation_Applications_2010.pdf or http://www.fs.fed.us/rm/pubs_other/rmrs_2007_evans_j001.pdf).
This is why I propose a p- and a n-flag for v.outlier, in order to be able to specify, that only positive or negative outliers are filtered. The attached code did the job for me. The attached two images illustrate my result when applying my modified version of v.outlier to my data rereatedly (similar to http://www.fs.fed.us/rm/pubs_other/rmrs_2007_evans_j001.pdf). On is a shaded relief of the DSM and the other a shaded relief of the DTM of the same region (after removing positive outliers).
Attachments (5)
Change History (10)
by , 13 years ago
Attachment: | v.outlier.diff added |
---|
comment:1 by , 13 years ago
Cc: | added |
---|---|
CPU: | Unspecified → All |
Milestone: | → 6.4.2 |
Platform: | Unspecified → All |
Version: | svn-trunk → svn-develbranch6 |
comment:2 by , 13 years ago
v.outlier
is not designed to separate first from last return of LiDAR point clouds. The purpose of v.outlier
is to detect true outliers, i.e. erroneous data points. First and last returns are not erroneous data points but valid data points. First and last returns can be separated with the LiDAR filtering toolchain v.lidar.*
, r.in.xyz
, and in grass 7 v.in.lidar
and r.in.lidar
.
Markus M
by , 11 years ago
Attachment: | v.outlier_G7.diff added |
---|
Adds a p- and a n-flag to v.outlier for only filtering positive or negative outliers
follow-up: 4 comment:3 by , 11 years ago
Milestone: | 6.4.2 → 7.0.0 |
---|---|
Version: | svn-develbranch6 → unspecified |
Recently we had another project where we got insufficient filtered LIDAR data, where especially returns from lower mountainous vegetation were classified as "ground return". Filtering only last return was already done in the classification process (applied by the LIDAR-operator) and therewith insufficient too. The multi-scale curvature classification (mcc) procedure developed by Evans & Hudak 2007 (PDF linked above) however helped filtering out at least some more vegetation returns. I created a GRASS 7 AddOn (python script) which applies the mcc procedure. It is not uploaded to svn yet and some more testing will be necessary in order to write a useful manual. But I could attach it as a prove of concept if that is of interest. However, it requires that the v.outlier.diff is applied. Therefore I would like to ask if the decision not to change v.outlier (because of the different concept of the module) could be reconsidered? The mcc-algorithm was really useful for us at least...
comment:4 by , 11 years ago
Replying to sbl:
Recently we had another project where we got insufficient filtered LIDAR data, where especially returns from lower mountainous vegetation were classified as "ground return". Filtering only last return was already done in the classification process (applied by the LIDAR-operator) and therewith insufficient too. The multi-scale curvature classification (mcc) procedure developed by Evans & Hudak 2007 (PDF linked above) however helped filtering out at least some more vegetation returns. I created a GRASS 7 AddOn (python script) which applies the mcc procedure. It is not uploaded to svn yet and some more testing will be necessary in order to write a useful manual. But I could attach it as a prove of concept if that is of interest. However, it requires that the v.outlier.diff is applied. Therefore I would like to ask if the decision not to change v.outlier (because of the different concept of the module) could be reconsidered? The mcc-algorithm was really useful for us at least...
I have added a new option to filter out only positive or only negative outliers in trunk r58414. Please note that this is a new option called filter, not two new flags.
comment:5 by , 11 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
code (svn diff)