Opened 4 years ago

Closed 4 years ago

#2932 closed defect (fixed)

z values read instead of intensity in

Reported by: dnewcomb Owned by: wenzeslaus
Priority: normal Milestone: 7.2.0
Component: Raster Version: svn-trunk
Keywords:, intensity, lidar Cc:
CPU: x86-64 Platform: Linux


The following command: -o -i -d --overwrite input=/data1/lidar_test/LA_37_20960803_20150430.las output=803_20ft_ground_intensity base_raster=D05_37_20960803_20141231@PERMANENT method=mean zrange=-10,0 class_filter=1,2,3,4,5,6,8,9,10,11,12,13,14,15,16,17,18

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.

Change History (8)

comment:1 Changed 4 years ago by wenzeslaus

The current implementation of -i uses intensity instead of z from the beginning and applies it for all subsequent operations:

if (intens_flag->answer)
    /* use z variable here to allow for scaling of intensity below */
    z = LASPoint_GetIntensity(LAS_point);
    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.

comment:2 Changed 4 years ago 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.

My apologies in not communicating properly

comment:3 Changed 4 years ago 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.

comment:4 Changed 4 years ago by neteler


Milestone renamed

comment:5 Changed 4 years ago 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

comment:6 Changed 4 years ago by wenzeslaus

Component: DefaultRaster
Keywords: intensity lidar added
Owner: changed from grass-dev@… to wenzeslaus
Status: newassigned

I did the proposed changes (-j, intensity_scale, intensity_range) in r68478. We can close this after some more testing.

comment:7 Changed 4 years ago by wenzeslaus

dnewcomb tested this, so closing, although the current test suite does not cover this.

comment:8 Changed 4 years ago by wenzeslaus

Resolution: fixed
Status: assignedclosed

Just to be clear about the branching, it is in 7.2:

Note: See TracTickets for help on using tickets.