Gives me a grid with values with negative numbers. LiDAR intensities are
always positive, so the mean values should also be positive. Since I have
only included Z values less in elevation than the ground surface, I assume
the values are from the Z coordinates.
#2932: z values read instead of intensity in r.in.lidar
-----------------------+-------------------------
Reporter: dnewcomb | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.1.0
Component: Default | Version: svn-trunk
Resolution: | Keywords:
CPU: x86-64 | Platform: Linux
-----------------------+-------------------------
Comment (by wenzeslaus):
The current implementation of `-i` uses intensity instead of z from the
beginning and applies it for all subsequent operations:
{{{
#!c
if (intens_flag->answer)
/* use z variable here to allow for scaling of intensity below */
z = LASPoint_GetIntensity(LAS_point);
else
z = LASPoint_GetZ(LAS_point);
}}}
Thus both `zrange` and `base_raster` are working with intensity. Is this
the behavior you observe?
I think it does not make much sense and `zrange` and `base_raster` always
using z is more expected and useful behavior. This raises two questions.
Does it make sense to have `intensity_range` or `irange` and
`intensity_scale`?
Is it OK to make this change when it is in fact changing behavior? Is the
previous behavior simply a bug, so we can just changed it? We are talking
about `zrange` and `zscale` (`base_raster` is 7.1 only). MarkusN added the
intensity in r61480 with the aforementioned comment ''allow for scaling of
intensity below''. Another flag (`-j` "stats on intensity, filters on z")
or even and option (`values=z|intensity|combined`) can implement this in a
backward compatible way for the price of complicating the interface and
the code.
#2932: z values read instead of intensity in r.in.lidar
-----------------------+-------------------------
Reporter: dnewcomb | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.1.0
Component: Default | Version: svn-trunk
Resolution: | Keywords:
CPU: x86-64 | Platform: Linux
-----------------------+-------------------------
Comment (by dnewcomb):
I think in this case the value of the increased functionality justifies
the increase in complexity. It was my (mistaken) understanding that you
could use the base raster and Z values to filter for the points you want
to analyse , then depending on whether the -i flag was set or not you
either the run the statistics on the Z values or run the statistics on the
intensity values.
This would allow you to look at the mean intensities of the points within
half a meter above and below the base raster surface or get the mean
intensities of the top 3 meters of the canopy. One could even acquire
intensity statistics in 2m horizontal sections of the canopy.
#2932: z values read instead of intensity in r.in.lidar
-----------------------+-------------------------
Reporter: dnewcomb | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.1.0
Component: Default | Version: svn-trunk
Resolution: | Keywords:
CPU: x86-64 | Platform: Linux
-----------------------+-------------------------
Comment (by dnewcomb):
Sorry to take so long to revisit this. The implementation that makes
most sense to me requires the presence of a base raster. Adding the -j
flag you suggested above might be the best way to go.
#2932: z values read instead of intensity in r.in.lidar
-----------------------+-------------------------
Reporter: dnewcomb | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.2.0
Component: Default | Version: svn-trunk
Resolution: | Keywords:
CPU: x86-64 | Platform: Linux
-----------------------+-------------------------
Comment (by wenzeslaus):
New proposed interface after discussion with dnewcomb at Code Sprint at
FOSS4G NA:
* `-j` - first do filtering on Z, then use intensity for statistics
* use case: intensity stats between 0.5 and 2 meters above the ground
* `intensity_scale` - scale intensity without using the `-i` flag
* use case: unifying datasets with different intensities when using `-j`
flag
* `intensity_range` - limit range of used intensities without using the
`-i` flag
* use case: filter out obvious outliers of intensities when using `-j`
flag