new lasoverage.exe flags, classifies, or removes points in the flight-line overlaps
閲覧: 771 回
最初の未読メッセージにスキップ
Martin Isenburg
2012/07/12 19:58:202012/07/12
To: last...@googlegroups.com
Hello,
the new tool called lasoverage.exe can be found in the latest release of LAStools (version 120712). This tool flags, classifies, or removes points in the overlapping areas between flight-lines of an airborne collect. It either marks these "overage" points or removes them from the output files. The tool requires that the files either have the flightline information stored for each point in the point source ID field (e.g. for LAS tiles containing overlapping flightlines) or that there are multiple files where each corresponds to a flightline (e.g. the '-files_are_flightlines' option). It is also required that the scan angle field of each point is populated. More detail here:
http://lastools.org/download/lasoverage_README.txt
Attached you see images from a tile in Iowa with 4 flight lines that are color-coded. You also see the result that overlapping flightlines have on the resulting hillshade DEM and if you toggle back and forth between the two you get a good sense of where the overlap is and what effect is has. While the resolution may be higher it also tends to create roughness as the flightlines are rarely perfectly aligned. Here the steps I took to generate this:
(1) find out which flight lines are in the tile
lasinfo -i iowa.laz -histo point_source 1
---> result was 4 flight lines: 10010, 10011, 10012, 10013
(2) show individual flight lines (press <0> <1> <2> <3> to toggle)
lasview -i iowa.laz -color_by_flight_line
(3) compute point density/spacing for individual flight line
lasinfo -i iowa.laz -compute_density -keep_point_source 10011
---> result was around 1.0 meter spacing
(4) classify overage points
lasoverage -i iowa.laz -step 2 -o iowa_no_over.laz
(5) show result without overlaps by dropping overage points
lasview -i iowa_no_over.laz -drop_class 12
(6) create hillshade DSM without overlaps
las2dem -i iowa_no_over.laz -drop_class 12 -hillshade -o iowa_no_over.png
Cheers,
Martin @rapidlasso
PS: Here an explaination based on what Karl Heidemann of the USGS once told me regarding "overlap" versus "overage" points: "Overlap" applies to any point in one flightline or swath that is anywhere within the boundary of another flightline. Whether or not a point is overlap is determined, basically, at the time of flight. It is a fundamentally immutable characteristic. "Overage" applies to any point not in the "tenderloin" of the flightline or swath, that is, the central core of the flightline that - when combined with the others - creates a non-overlapped and gap-less coverage of the surface. Whether or not a point is overage is determined by the operator (or software) that defines the single-coverage tenderloins of the flightlines. Hence, it is a subjective characteristic -- it depends solely on where somebody (here: lasoverage.exe) chooses to draw the boundary. The LAS specifications use the word "overlap" where they should be using the word "overage".
the new tool called lasoverage.exe can be found in the latest release of LAStools (version 120712). This tool flags, classifies, or removes points in the overlapping areas between flight-lines of an airborne collect. It either marks these "overage" points or removes them from the output files. The tool requires that the files either have the flightline information stored for each point in the point source ID field (e.g. for LAS tiles containing overlapping flightlines) or that there are multiple files where each corresponds to a flightline (e.g. the '-files_are_flightlines' option). It is also required that the scan angle field of each point is populated. More detail here:
http://lastools.org/download/lasoverage_README.txt
Attached you see images from a tile in Iowa with 4 flight lines that are color-coded. You also see the result that overlapping flightlines have on the resulting hillshade DEM and if you toggle back and forth between the two you get a good sense of where the overlap is and what effect is has. While the resolution may be higher it also tends to create roughness as the flightlines are rarely perfectly aligned. Here the steps I took to generate this:
(1) find out which flight lines are in the tile
lasinfo -i iowa.laz -histo point_source 1
---> result was 4 flight lines: 10010, 10011, 10012, 10013
(2) show individual flight lines (press <0> <1> <2> <3> to toggle)
lasview -i iowa.laz -color_by_flight_line
(3) compute point density/spacing for individual flight line
lasinfo -i iowa.laz -compute_density -keep_point_source 10011
---> result was around 1.0 meter spacing
(4) classify overage points
lasoverage -i iowa.laz -step 2 -o iowa_no_over.laz
(5) show result without overlaps by dropping overage points
lasview -i iowa_no_over.laz -drop_class 12
(6) create hillshade DSM without overlaps
las2dem -i iowa_no_over.laz -drop_class 12 -hillshade -o iowa_no_over.png
Cheers,
Martin @rapidlasso
PS: Here an explaination based on what Karl Heidemann of the USGS once told me regarding "overlap" versus "overage" points: "Overlap" applies to any point in one flightline or swath that is anywhere within the boundary of another flightline. Whether or not a point is overlap is determined, basically, at the time of flight. It is a fundamentally immutable characteristic. "Overage" applies to any point not in the "tenderloin" of the flightline or swath, that is, the central core of the flightline that - when combined with the others - creates a non-overlapped and gap-less coverage of the surface. Whether or not a point is overage is determined by the operator (or software) that defines the single-coverage tenderloins of the flightlines. Hence, it is a subjective characteristic -- it depends solely on where somebody (here: lasoverage.exe) chooses to draw the boundary. The LAS specifications use the word "overlap" where they should be using the word "overage".
Veldman, Edgar
2012/08/08 6:02:532012/08/08
To: last...@googlegroups.com
Hi Martin,
I noticed the jagged overlap edge between swaths in your screenshots and assumed that was because your data was maybe captured from an unstable platform, possibly a small helicopter or a remotely controlled unmanned aircraft…
But when I finally got around testing this on some of our data (captured from a fixed wing airplane, Leica sensor), I noticed the same jaggedness in the overlap definition. This is not what I was used to with our data, and also not what are clients are used to.
Would there be a setting I can use to avoid this from happening? I would rather have a neat edge between swaths if possible.
Or do you have some more information on how this edge is defined, so that I can maybe tweak the input data to make it work?
Some screenshots to clarify:
Input data
Overlap removed by Lastools
Overlap removed by another tool
Thanks,
Edgar
--
Download LAStools at
http://lastools.org/
Visit the LAStools group at
http://groups.google.com/group/lastools/
Be social with LAStools at
http://www.facebook.com/LAStools
http://www.twitter.com/LAStools
Martin Isenburg
2012/08/08 6:24:102012/08/08
To: last...@googlegroups.com
Hello Edgar,
You cannot expect get a straight line here without me writing a new tool. (-:
Regards,
Martin @rapidlasso
On Wed, Aug 8, 2012 at 3:02 AM, Veldman, Edgar <e.ve...@fugrospatial.com.au> wrote:
But when I finally got around testing this on some of our data (captured from a fixed wing airplane, Leica sensor), I noticed the same jaggedness in the overlap definition. This is not what I was used to with our data, and also not what are clients are used to.
Yes, the edge in the overlap area between two flight lines that is defined by
marking the overage points with lasoverage.exe and then excluding them
from subsequent processing can be expected to be jagged due to the way
the tool decides which points to keep in overlap areas.
Is there anything inherently "better" about this dividing line being "straight" other than it being what another software produces? Some people actually prefer the "natural" look of my dividing line as it is - in case of a slight flight-line misalignment - much less prominent than a straight when you render a hill-shade of the terrain.
Is there anything inherently "better" about this dividing line being "straight" other than it being what another software produces? Some people actually prefer the "natural" look of my dividing line as it is - in case of a slight flight-line misalignment - much less prominent than a straight when you render a hill-shade of the terrain.
Would there be a setting I can use to avoid this from happening? I would rather have a neat edge between swaths if possible. Or do you have some more information on how this edge is defined, so that I can maybe tweak the input data to make it work?
You cannot expect get a straight line here without me writing a new tool. (-:
Regards,
Martin @rapidlasso
Martin Isenburg
2012/08/08 10:03:392012/08/08
To: LAStools - efficient tools for LiDAR processing
Hello,
I just received a message from Lewis Graham that did not make it
through to the list. He wrote:
Another consideration:
A typical reason for marking points in overlap regions as Withheld and/
or Overlap (in LAS 1.4) is due to the fact that the horizontal and
vertical accuracy of the LIDAR data is a function of the scan angle
from nadir (at least in airborne sensors using beam scanning),
decreasing as one moves away from nadir. Cutting as Martin cuts
ensures more uniform edge accuracy of the data. A straight-line cut
results in variable accuracy. Of course, one may not care about this
phenomenon and be looking only for a pretty picture….
_______________________________
Lewis Graham
I just received a message from Lewis Graham that did not make it
through to the list. He wrote:
Another consideration:
A typical reason for marking points in overlap regions as Withheld and/
or Overlap (in LAS 1.4) is due to the fact that the horizontal and
vertical accuracy of the LIDAR data is a function of the scan angle
from nadir (at least in airborne sensors using beam scanning),
decreasing as one moves away from nadir. Cutting as Martin cuts
ensures more uniform edge accuracy of the data. A straight-line cut
results in variable accuracy. Of course, one may not care about this
phenomenon and be looking only for a pretty picture….
_______________________________
Lewis Graham
Martin Isenburg
2012/10/02 16:50:252012/10/02
To: LAStools - efficient tools for LiDAR processing
Hello,
the discussion in lasoverage was a fairly important one and I have resolved it in an off-line follow up discussion. Edgar send me the LAS tiles in question and these attached as well as a few other screen shots. Edgar wrote: "With regards to your comments, and Lewis’ reply, we are not just after a nice picture. It would make sense if the jaggedness would be related to scan angle or terrain elevation, but I can’t see a relationship there. It looks like the edge is drawn at very random locations. There is probably a logic algorithm working behind the scenes but I can’t recognize it. Also, if the jaggedness would not be so spiky in places, it would maybe not be noticeable, but the noisiness and zigzag pattern I see with the overlap definition has raised some eyebrows."
And indeed, it had me baffled how the "other" software was doing such wonderfully straight cuts. How did they do it. Well ... turns out the "other" software was using the flight trajectory information to make those cute (you can actually see these auxiliary lines in the images) whereas LAStools was making its decision purely based on the scan angles stored per point. So in the end (see next email) we agreed that LAStools was - in fact - picking the points with the lowest absolute scan angle. Whether this is necessarily the best choice if the aircraft experiences heavy roll is a whole different question ... after all, the nadir scan angle only corresponds to the scan angle with the value zero when the aircraft is level.
Regards,
Martin @rapidlasso
the discussion in lasoverage was a fairly important one and I have resolved it in an off-line follow up discussion. Edgar send me the LAS tiles in question and these attached as well as a few other screen shots. Edgar wrote: "With regards to your comments, and Lewis’ reply, we are not just after a nice picture. It would make sense if the jaggedness would be related to scan angle or terrain elevation, but I can’t see a relationship there. It looks like the edge is drawn at very random locations. There is probably a logic algorithm working behind the scenes but I can’t recognize it. Also, if the jaggedness would not be so spiky in places, it would maybe not be noticeable, but the noisiness and zigzag pattern I see with the overlap definition has raised some eyebrows."
And indeed, it had me baffled how the "other" software was doing such wonderfully straight cuts. How did they do it. Well ... turns out the "other" software was using the flight trajectory information to make those cute (you can actually see these auxiliary lines in the images) whereas LAStools was making its decision purely based on the scan angles stored per point. So in the end (see next email) we agreed that LAStools was - in fact - picking the points with the lowest absolute scan angle. Whether this is necessarily the best choice if the aircraft experiences heavy roll is a whole different question ... after all, the nadir scan angle only corresponds to the scan angle with the value zero when the aircraft is level.
Regards,
Martin @rapidlasso
Martin Isenburg
2012/10/02 17:09:192012/10/02
To: LAStools - efficient command line tools for LIDAR processing
Hello again,
I created these two visualizations with lasgrid to prove that lasoverage was doing "the best it could" given that it has no access to the original flight trajectories and that it indeed follows the "lowest absolute scan angle" it finds in the data.
I created these two visualizations with lasgrid to prove that lasoverage was doing "the best it could" given that it has no access to the original flight trajectories and that it indeed follows the "lowest absolute scan angle" it finds in the data.
lasgrid -i 624000-7541000.laz -scan_angle_abs -lowest -false -opng -odix _scan_abs -step 2
lasgrid -i 617000-7548000.laz -scan_angle_abs -lowest -false -opng -odix _scan_abs -step 2
When one looks at the way the shading flows one quickly realizes that the colors not only look pretty, but also explain why lasoverage was choosing the points the way it did in the images from the last message where Edgar was comparing lasoverage with the "other" software.
Regards,
Martin @rapidlasso
lasgrid -i 617000-7548000.laz -scan_angle_abs -lowest -false -opng -odix _scan_abs -step 2
When one looks at the way the shading flows one quickly realizes that the colors not only look pretty, but also explain why lasoverage was choosing the points the way it did in the images from the last message where Edgar was comparing lasoverage with the "other" software.
Regards,
Martin @rapidlasso
Tobias K Kohoutek
2016/05/26 5:26:302016/05/26
To: LAStools - efficient tools for LiDAR processing
Hi Martin,
I've a problem in the most actual version of lasoverage and it doesn't matter if I use the GUI or batch file processing.
If I don't select -merge but set -faf respectively -files_are_flightlines, I receive the following by loading flightlines (not tiled) las-files:
Warning: input has only one flightline ID 0. there is no overlap to compute.
I checked the raw_strips with lasinfo, each has a different file source ID (0 - 17) while point_source_ID is always 0.
Using -merge results in the classification of overlapping points which are classified as 12, the flightline ID in the resulting merged cloud is 0 and point_source_ID varied from 0 - 17 like expacted.
So my question is, why doesn't lasoverage work if I don't merge the flightlines?
I mean I could go the long way and merge them and then while tiling with lastile split the cloud, but then I've the problem that one can't chose -color_by_flightline anymore in lasview because the point_source_ID isn't taken into account in this case as flightline number.
Cheers,
Tobias
Martin Isenburg
2016/07/26 13:56:142016/07/26
To: LAStools - efficient command line tools for LIDAR processing
Hello Tobias,
sorry ... it took me a while to work my way back to this question. If you use 'lasoverage' with multiple flightlines being stored in different files as input then the process must be running on a single core to make comparisons between the different points from the different. As I did not disable the '-cores 2' functionality when either '-files_are_flightlines' or '-apply_flight_source_ID' are selected the lasoverage was spawning child processes, each trying to compute an overlap using only the single assigned flightline as input. Hence, the problem was not using or not using the '-merged' command (which also disables running on multiple cores) but the presence of the '-cores 4' or so in your command line. The next version of 'lasoverage' will automatically disable the multi-core functionality in this situation.
Below a small example of how the command-line is "fixing itself" in the next release.
Regards,
Martin @rapidlasso
=====================
D:\LAStools\bin>lasoverage -v -i strips_raw\*.laz -faf ^
-odir strips_overage -olaz -cores 2
WARNING: input files are flightlines. ignoring '-cores 2' ...
processing file 'strips_raw\strip1.laz' with 515006 points.
processing file 'strips_raw\strip2.laz' with 1128339 points.
processing file 'strips_raw\strip3.laz' with 425760 points.
processing file 'strips_raw\strip4.laz' with 1085293 points.
processing file 'strips_raw\strip5.laz' with 3134 points.
took 2.41 sec. computing flightline overage.
took 0.031 sec. outputting ...
took 2.523 sec. found 2107499 overage points.
done with 5 files. total time 4.964 sec.
--
Download LAStools at
http://lastools.org
Be social with LAStools at
Tobias K Kohoutek
2016/09/06 8:18:572016/09/06
To: LAStools - efficient tools for LiDAR processing
Hello Martin and everybody else who helped me out so far,
we're struggeling with another problem we discovered using lasoverage. It seems like somescan lines, in some specific areas where flight lines have overaging areas, are eliminated completely from the point cloud. Sometimes it seems like it's only one scan line while othertimes it seems to be 2 - 3 scan lines that are missing. Attached is an example.
My question is, is the chosen step size too big or too small to search and eliminate overage?
Thanks and greetings from Chile,
Tobias
全員に返信
投稿者に返信
転送
新着メール 0 件