Method to determine adjacent lidar file using LAStools?

[Blake Lytle]

Hello group,

Is there a method using LAStools to determine which lidar files are adjacent for buffering purposes?

Background:

I am creating a processing workflow on a computing cluster to perform a variety of operations on a US county's worth of Lidar at a time. This is generally a few hundred to few thousand adjacent LAZ files, and for this example, let's assume I want to create a DTM.

I am aware of the benefits of working with buffered tiles created from (i.e. within) a single LAS. No edge effects. Beautiful.

When working with pre-tiled data, I cannot buffer these files without knowing which are adjacent. I can use GIS to determine this (i.e. get bounding boxes using lasboundary and GIS to assess neighbors, write neighbors to a table, merge adjacent files and then clip using a buffered extent) but it's not ideal.

Any suggestions?

[Terje Mathisen]

If you tile your data using lastile, then the location of each tile is
directly encoded in the tile name, making it trivial to determine which
tiles are the neighbors. You should probably run lasindex before you
tile, I prefer to let lastile create buffered tiles directly since from
that point each tile can be processed completely independently, i.e.
"embarrasingly parallelizable".

I believe LAStools now also have the capability to "buffer on the fly"
quite efficiently, if you start with indexed tiles, but I have never
tested this myself.

Terje
> --
> 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


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

[Blake Lytle]

Yes, that's true. But I am working with data that were tiled by a vendor, not by me, so their naming convention is based on flight date rather than coordinates. I need to determine which of these files are adjacent so I can buffer them for DTM generation.

[Kirk Waters - NOAA Federal]

When you run lastile, it will create new names for the output tiles, including location information. The old naming convention will be gone. 

Kirk

[Blake Lytle]

Yes, again, that's true, but not what I'm asking: The problem I am trying to solve is that I obtain a large set of pre-tiled data and I need to buffer each of these using their adjacent files to remove edge effects in the output DTM. To alleviate this, I want to merge adjacent files and clip them out with an additional buffer. This requires merging each existing file with it's neighboring files, but I need a method to determine which are adjacent. I want to know if LAStools somehow has this capability.

[Susana Gonzalez]

Hi there,

As Terje said do first lasindex (this tool will figure out who is the neighbour tile)

 

lasindex.exe -i %DATA%\*.laz -append -cores 30

 

and then you could do a buffer of 50m

 

lastile.exe -i %LIDAR% -tile_size 500 -buffer 50 -odir %TILE_b50% -olaz   (the output name would be XXXXX_YYYYY.laz, so you know the location of the tile)

 

Then do the DTM with a buffer of 50m, be aware that the borders of these rasters would be wrong because of the triangulation

 

blast2dem.exe -i %TILE_b50%\*.laz -keep_class 2 -step 0.3 -odir %DTM_b50% -odix _dtm -otif -cores 30

 

You can’t remove a buffer in a raster (-remove_buffer) so you would need to compute where is your low left coordinate to delete the 50m buffer.

 

In this case I only want to remove 20m from the original 50m buffer ( I do this in python, extracting the coordinates from the name and take off 20m of the buffer), but may be Martin could create an automatic switch -remove_buffer 20 ???

lasgrid.exe -i %DTM_b50%\name_dtm.tif -step 0.3 -ncols 1800 -nrows 1800 -ll (xll-20) (yll-20) -odir %DTM%\name_dtm.tif

 

Good luck!

Susana

[Terje Mathisen]

Blake Lytle wrote:

Yes, that's true. But I am working with data that were tiled by a vendor, not by me, so their naming convention is based on flight date rather than coordinates. I need to determine which of these files are adjacent so I can buffer them for DTM generation.

OK, this means you have exactly the same situation as I do here in Norway!

I simply re-tile everything, including a 35m buffer for each tile, i.e. lasindex followed by lastile -cores 7.

At the very end, when merging individual raster images back together, I can use the tile names to clip each raster to the original boundaries and merge them with very nearly zero edge artifacts. The same goes for vector data like contour lines which I clip to the tile boundary after generation.

As Susana Gonzales suggested it would be extremely useful if LAStools could get a post-processing filter to remove any buffer area, for both vector and raster data, this could obviate my custom code to handle these issues.

Terje

[Martin Isenburg]

Hello,

if you have a folder full of tiled and classified LAS or LAZ files that do not have a buffer you can create ground point DTMs, first-return DSMs, or spike-free DSMs without edge effects using the on-the-fly buffering feature in LAStools. This is the second example in this blog post:

https://rapidlasso.com/2015/08/07/use-buffers-when-processing-lidar-in-tiles/

Building upon Susana's command-line examples you should first index the LAS or LAZ tiles with lasindex which will create a small LAX file per each LAS or LAZ tile

lasindex -i unbuffered_tiles\*.laz ^

              -cores 30

 

Then you can do on-the-fly buffering (here with a 50 meter buffer) to create a ground point DTM with las2dem (or blast2dem). The command line switch '-buffered 50' creates a 50 meter (or feet) buffer on-the-fly and the switch '-keep_orig_bb' makes sure only the original center extend of the now-buffered tile gets rastered.

las2dem.exe -i unbuffered_tiles\*.laz ^

                       -buffered 50 ^

                       -keep_class 2 ^

                       -step 0.5 ^

                       -keep_orig_bb ^

                       -odir dtm_50cm -otif ^

                       -cores 4

Similarly you can create a first-return DSM. Again the command line switch '-buffered 50' creates a 50 meter (or feet) buffer on-the-fly and the switch '-keep_orig_bb' makes sure only the original center extend of the now-buffered tile gets rastered.

las2dem.exe -i unbuffered_tiles\*.laz ^

                       -buffered 50 ^

                       -keep_first ^

                       -step 0.5 ^

                       -keep_orig_bb ^

                       -odir dsm_50cm_fr -otif ^

                       -cores 4

 

Or a first-return DSM. Again the command line switch '-buffered 50' creates a 50 meter (or feet) buffer on-the-fly and the switch '-keep_orig_bb' makes sure only the original center extend of the now-buffered tile gets rastered.

las2dem.exe -i unbuffered_tiles\*.laz ^

                       -buffered 50 ^

                       -spike_free 1.2 ^

                       -step 0.5 ^

                       -keep_orig_bb ^

                       -odir dsm_50cm_fr -otif ^

                       -cores 4

Under the hood LAStools figures out which neighbor files need to be used to on-the-fly read the buffer points for each tile.

Regards.

Martin @rapidlasso

[Blake Lytle]

Martin, Susana, Terje,

Thank you for clarifying and the excellent example codes. I did not understand that the LAStools had the "under the hood" capability for on-the-fly buffering. I will run a test with your examples and let you know how it goes!

Blake