Scrutinizing LiDAR Pulse Density and Spacing

[Martin Isenburg]

Hello,

Working with LiDAR data scanned with different hardwares one cannot help but notice the distinctively different scan patterns. How do these affect pulse density and pulse spacing. In this article we demonstrate that "average point density" and/or "average point spacing" are simply not good enough quality measures to properly quantify the point distribution across an entire flightline ... especially not for scanners with oscillating mirrors.

http://rapidlasso.com/2014/03/20/density-and-spacing-of-lidar/

Errors? Objections? Additions?

Regards,

Martin @rapidlasso

--

http://rapidlasso.com - fast tools to space your LiDARs

[Terje Mathisen]

Martin Isenburg wrote:
> Hello,
>
> Working with LiDAR data scanned with different hardwares one cannot help
> but notice the distinctively different scan patterns. How do these
> affect pulse density and pulse spacing. In this article we demonstrate
> that "average point density" and/or "average point spacing" are simply
> not good enough quality measures to properly quantify the point
> distribution across an entire flightline ... especially not for scanners
> with oscillating mirrors.
>
> http://rapidlasso.com/2014/03/20/density-and-spacing-of-lidar/
>
> Errors? Objections? Additions?

Nice writeup, as usual. :-)

The only downside I can see with the RIEGL scanning pattern would be
that the scanning density along the beam direction, i.e. perpendicular
to the flight direction, will depend upon the scan angle:

With a constant scanning frequency and a constant rotational speed of
the scanner, points closer to the edge of the swath will be a little
further apart than those directly below the flight line, simply due to
the increased distance.

Anyway, it sure looks like this is the better option if you get to
choose the gear to be used for a scanning job.

Terje

--
- <Terje.M...@tmsw.no>
"almost all programming can be viewed as an exercise in caching"

[Martin Isenburg]

Hello,

in practice it seems folks are removing the edge of flightlines scanned with oscillating mirrors by clipping all points that have a scan angle above a certain threshold before the flight lines are merged  and tiled. What scan angle rank thresholds are typically used for this? When is this typically done? Before or after aligning the flightlines with the LMS software? Before or after the quality checking? Before or after the tiling? Only on-the-fly when producing deliverables? Here some suggestions:

las2las -i raw\*laz ^
             -drop_abs_scan_angle_above 20 ^

             -odir without_edges -olaz 

las2las -i raw\*laz ^
             -drop_abs_scan_angle_above 25 ^

             -rescale 0.01 0.01 0.01 ^

             -odir without_edges -olaz 

           

las2las -i raw\*laz ^
             -drop_scan_angle_above 22.5 ^

             -drop_scan_angle_below -22.5 ^

             -odir without_edges -olaz 

Can share some in-house workflows? I would like to repeat these experiments (a) on flightlines that are cut down to commonly used scan angle rank ranges and (b) on the tiles produced after merging adjacent flightlines with (or without?) keeping all overlap points.

Regards,

Martin @rapidlasso

PS1: Prof. Phisan from Chulalongkorn University pointed out a related article from Ty Naus that uses the *average* edge lengths of the Delaunay triangulation of last returns to compute the pulse spacing and the area of the dual Voronoi cells as the density measurement for creating those histograms.

http://www.asprs.org/a/publications/proceedings/Milwaukee2011/files/Naus.pdf

I think the longest and shortest edge histograms suggest that using *averaged* edge lengths is not such a good idea, as this will "average away" the different spacings we observe in along scanline and between scanlines for oscillating scans when using the entire scan angle range.

PS2: Another interesting comment (that bounced) came from Ilves Risto of the National Land Survey of Finland. He writes

"Nice analysis, but you should also think about the productivity (i.e. data acquisition costs). It's important notice parameters like flying speed, altitude and FOV. Especially demanded FOV is important. If it's required to have different FOV, then oscillating systems are more flexible.

When you are collecting data (or ordering it), you should defined the minimum requirements for the point density and distribution. Then it's not critical, if you get better data in some parts of the strip. These requirements should be checked in the areas, where the used scan pattern has most probably biggest problems. Typically the edge of the flight line is in the overlapping area, so it's not so critical and it's more important check point distribution in the nadir.

It would be nice, if you could select the number of rotating mirrors (i.e. FOV) for RIEGL. I would choose 40 degrees (9 mirrors) for our needs, because the flying speed could be higher. But then you also need a stabilized mount, since you can't use roll compensator, which is available for the oscillating system.

For some application, the even spacing is not best solution. E.g. if you are scanning power line, you want to have hits to the wires. This means that ideal scanning patter is such that the footprints are overlapping across the flight direction.

In practice, oscillating systems are more efficient for certain applications and flying parameters. Personally, I don't see this so big issue, because both systems have good and bad aspects. The question is more, what is your needs and how you use the system."

[Heidemann, Hans]

The practice of trimming of the edges is wholly unacceptable in all cases.

LAS provides a bit flag to identify and isolate whatever points the data producer determines to be geometrically unusable. It's called "Withheld", and the provision for it was introduced into LAS at v1.1, adopted by ASPRS on May 7, 2005. It was put there for a functional reason.  It is high time the industry started using the functionality of the format the industry developed. 

Karl

H. Karl Heidemann, GISP

Physical Scientist, Lidar Science

U.S. Geological Survey

Mundt Federal Building

47914 252nd Street

Sioux Falls, SD  57110

605-594-2861

kheid...@usgs.gov

"Nothing matters very much, and very few things ... matter at all."

- Arthur James Balfour

--
Download LAStools at
http://lastools.org
http://rapidlasso.com
Be social with LAStools at
http://facebook.com/LAStools
http://twitter.com/LAStools
http://linkedin.com/groups/LAStools-4408378
Manage your settings at
http://groups.google.com/group/lastools/subscribe

[Evon Silvia]

I don't think there's a one-size-fits-all definition for point density.

Perhaps the most sensible solution is to specify an overall point density for a project, and then require that that density be met in some percentage of the cells of a mid-resolution density raster. The exact values (first/last/all returns? 10m or 100m cells? 80% or 95% of cells?) used would depend strongly on the end-use of the data. 

We often do edge clips regularly for our Leica and Optech data, but I haven't seen anyone mention our main reason for doing so in this discussion: the position and distortion of an oscillating mirror during the direction change is very poorly modeled by the processing software. Points at the edge regularly "stack up" on top of each other, creating artifacts in the data such as fake trees and artificial oscillations in the ground model. It is far simpler to clip this edge and plan a little extra overlap than to allow unnecessary clutter in the dataset that must be cleaned.

Is there any software out there that uses the edge/withheld/synthetic flags and allows their modification? As far as I know, it is impossible to flag a process (e.g., hillshading) in TerraSolid or LAStools to exclude/ignore (not remove) points flagged as scan edge or withheld, so one must first remove those points, run some processes, and add them back in later.

Interesting conversation you started here, Martin.

Evon

--

Evon Silvia  Geomatics Specialist

P: 541-752-1204 | E: esi...@quantumspatial.com | W: wsidata.com 

WSI Corvallis, OR WSI Portland, OR WSI Oakland, CA

517 SW 2nd St., Suite 400, Corvallis, OR 97333

[Martin Isenburg]

Hello,

a typical LAStools command-line sequence for employing the 'withheld' flag would be

lasoverage -i tiles_classified\*.laz ^

                    -flag_as_withheld ^

                    -odir tiles_overaged -olaz ^

                    -cores 7

las2dem -i tiles_overaged\*.laz ^

                -drop_withheld -keep_class 2 ^

                -use_tile_bb -hillshade ^

                -odir tiles_hillshade -opng ^

                -cores 7

or - for better I/O performance and less data storage - with LASlayers

lasoverage -i tiles_classified\*.laz ^

                    -flag_as_withheld ^

                    -olay ^

                    -cores 7

las2dem -i tiles_overaged\*.laz -ilay ^

                -drop_withheld -keep_class 2 ^

                -use_tile_bb -hillshade ^

                -odir tiles_hillshade -opng ^

                -cores 7

Cheers,

Martin @rapidlasso

[Karl Heidemann]

Point is, ALL software needs to implement the proper exploitation of the withheld, and overage, flags. And quickly. It isn't like they haven't had time, and to think that nobody would ever require the functionality is tragically short-sighted. Neither is THAT difficult.

Sent from my Verizon Wireless 4G LTE DROID

[Heidemann, Hans]

On Mon, Mar 24, 2014 at 12:22 PM, Evon Silvia <esi...@quantumspatial.com> wrote:

I don't think there's a one-size-fits-all definition for point density.

Correct. There isn't a  "one-size-fits-all definition for point density". But there needs to be. Because when a customer says they want X density of points, both Vendor A and Vendor B need to give him answers that are based on the same definition, and that definition has to match the customer's. The engineers can go back to the lab and discuss density in whatever terms they like, but out in the real world, there has to be a common vocabulary.

Perhaps the most sensible solution is to specify an overall point density for a project, and then require that that density be met in some percentage of the cells of a mid-resolution density raster. The exact values (first/last/all returns? 10m or 100m cells? 80% or 95% of cells?) used would depend strongly on the end-use of the data. 

Correct. The basis of what you are saying is, there needs to be a common, accepted definition for point density. The USGS-NGP Lidar Specification v1.0 provides one: 

• First (or Last) Returns only. 
  
• Single-Swath, full width minus 5% from each side edge. 
  
• Square root of the average area per point, excluding acceptable voids such as water bodies. etc.
  
• Along and Cross-track spacings within 10% (of the specified NPS)

(v1.1 makes some adjustments to those definitions)

This definition may not be agreeable to everybody in the industry, but that document was reviewed extensively, for a period of years, and I have yet to receive an alternative definition.

 

We often do edge clips regularly for our Leica and Optech data, but I haven't seen anyone mention our main reason for doing so in this discussion: the position and distortion of an oscillating mirror during the direction change is very poorly modeled by the processing software. Points at the edge regularly "stack up" on top of each other, creating artifacts in the data such as fake trees and artificial oscillations in the ground model. It is far simpler to clip this edge and plan a little extra overlap than to allow unnecessary clutter in the dataset that must be cleaned.

Correct. The extreme edges of swaths collected from oscillating mirror systems have some geometric "issues", and thus are not desirable in the ground model. However, lidar is about more than a ground model. A LOT more. Here at the USGS, we have scientific and research interests in other exploitations of the lidar point cloud data, as well as investigation of the data itself. Hence, we require delivery of the complete point cloud. If the point is collected, the point is delivered. To those who think the bare-earth DEM is both the Alpha and the Omega, that may not even seem rational, but to us, it is.

Is there any software out there that uses the edge/withheld/synthetic flags and allows their modification? As far as I know, it is impossible to flag a process (e.g., hillshading) in TerraSolid or LAStools to exclude/ignore (not remove) points flagged as scan edge or withheld, so one must first remove those points, run some processes, and add them back in later.

The LAS Specification has, for 9 years, provided the functionality to "virtually remove" any points the data producer regards as geometrically unusable from the file. The mechanism is to flag them as "Withheld" in the file, and for software to then recognize this flag and exclude those points from any and all operations (except export), unless the user explicitly directs it to re-include them. If software had been written to use the file format as intended, there would be no need to remove and re-add points from the file itself. I believe LP360 now does this.

The driver here is the LAS Specification, not the availability of function A or B in somebody's current software. If the software will not support the specification, and the adherence to the specification is required by the collection contract, the issue is between the data producer(s) and their software developer(s).

 

Interesting conversation you started here, Martin.

Not to detract from Martin :-) , but this conversation has been going on for years.

I continue to look forward to the day it ENDS.

[Ian Madin]

At the Oregon Lidar Consortium we specify a minimum pulse density, not point density, and specify how that is measured:

"Survey must be designed for 100% double coverage at planned aircraft height above the ground.  The aggregate design multi-swath pulse density must be 8.0 pulses per square meter or higher. "

"

1. Aggregate first return density: Barring non-scattering areas (e.g. open water, wet asphalt).
   1. For any entire project area, must be greater than or equal to 95% design pulse density.
   2. Within any 30m x 30m area within swath overlap, must be greater than or equal to 80% design pulse density."

We recently upgraded our specification and deliverables, and would be happy to provide it on request.

---

From: last...@googlegroups.com [last...@googlegroups.com] on behalf of Heidemann, Hans [kheid...@usgs.gov]
Sent: Wednesday, March 26, 2014 11:08 AM
To: last...@googlegroups.com
Subject: Re: [LAStools] Scrutinizing LiDAR Pulse Density and Spacing