I have a las catalog with overlapping tiles. LidR warns me of this, and I'm wondering how concerned I should be. The tiles are in las version 1.2 with point record format 1. None of the points are marked as Withheld so there is no filtering to be done. I did a test on two of the tiles and found that the area of the intersection is 2200 square meters, and each of the tiles are about 225 hectares. This seems like a relatively small portion of overlap. Do I need to modify the tiles? Or can I process them like normal?

Las Check:

> lascheck(ctg)

 Checking headers consistency
 - Checking file version consistency... ✓
 - Checking scale consistency... ✓
 - Checking offset consistency... ✓
 - Checking point type consistency... ✓
 - Checking VLR consistency... ✓
 - Checking CRS consistency... ✓
 Checking the headers
 - Checking scale factor validity... ✓
 - Checking Point Data Format ID validity... ✓
 Checking preprocessing already done 
 - Checking negative outliers... ✓
 - Checking normalization... no
 Checking the geometry
 - Checking overlapping tiles...
    ⚠ Some tiles seem to overlap each other
 - Checking point indexation... no
 - List item

Catalog Info:

> ctg
class       : LAScatalog
extent      : 554999.8 , 562500.1 , 4555500 , 4561501 (xmin, xmax, ymin, ymax)
coord. ref. : NA 
area        : 33.61 kunits²
points      : 370.01 million points
density     : 11 points/units²
num. files  : 16

Catalog Plot: enter image description here

  • If the tiles overlap it should be a very tiny overlap according to the picture. Can you give us more information about the catalog
    – JRR
    Dec 25, 2019 at 2:09
  • @JRR I have added some more general info about the catalog. Is there anything in particular that would be helpful?
    – Lucas
    Dec 25, 2019 at 4:30

2 Answers 2


In lidR a buffer is loaded on the fly when you process a collection of files by chunk. If some files are overlapping each other you have a warning to alert you about potential problems. The reason you will encounter issues is because you will load twice the points. I can see few classical cases of overlapping files that actually happened to me.

The files are already buffered

In this case lidR will load twice the buffered region and this will result in some dummy statistic, double tree counting, increasing processing time and probably other troubles. If the buffering is properly done, buffer points are likely to be flagged. For example flagged as withheld. You can filter them at read time

opt_filter(ctg) <- "-drop_withheld"

The files are flightlines

When a file records a single flight transect, files are overlapping, of course, but this does not create regions with duplicated points. You can process normally and ignore the message. The engine will take care of making independent and buffered chunks.

There are some duplicated files

A few tiles that appears more than once. When plotting, the light blue being transparent, the overlapping regions should appears darker. You must remove these files.


There are plenty of other explanations. Headers may be incorrectly populated, points may have been reprojected (this is likely the case below) and one may find other specific cases I have never thought about.

In your case, the collection looks good. The overlapping is very tiny. You must find why you have overlapping regions and if it was intended by the provider or not. Overlapping is not an issue by itself. The problem is duplicated points. I suggest you to apply few geometry operations to check your catalog and find where are the overlaps. For examples:

#> Le chargement a nécessité le package : raster
#> Le chargement a nécessité le package : sp

# Overlapping
ctg1 = readLAScatalog("BCTS/")
#> Be careful, some tiles seem to overlap each other. lidR may return incorrect outputs with edge artifacts when processing this catalog.

# Not overlapping
ctg2 = readLAScatalog("Campbell River/")


# Not overlapping catalog are expected to be unchange by union
spdf1     <- as.spatial(ctg1)
contour1 <- rgeos::gUnaryUnion(spdf1)

spdf1     <- as.spatial(ctg2)
contour2 <- rgeos::gUnaryUnion(spdf1)


# Compare the areas
round(contour1@polygons[[1]]@area, 4)
#> [1] 106817079
round(area(ctg1), 4)
#> [1] 111099479

round(contour2@polygons[[1]]@area, 4)
#> [1] 22133936
round(area(ctg2), 4)
#> [1] 22133936

Created on 2019-12-25 by the reprex package (v0.3.0)

  • What do you mean by "The files are flightlines"?
    – Lucas
    Dec 28, 2019 at 12:07
  • A file records a single flight transect, edited for clarity.
    – JRR
    Dec 28, 2019 at 12:41
  • Ok, then it is not the case that the files are flightlines. The metadata states that the coverage includes 499 flight lines, but there are many more tiles than this.
    – Lucas
    Dec 28, 2019 at 13:03
  • @JRR Looking for some clarification. If a certain area has multiple flight lines, I would not be wrong to load the (overlapping) data in a catalog and process further for ABA?
    – K_D
    Jan 17, 2020 at 15:34
  • Overlapping data from different flightlines are not duplicated points. It is not a problem programmatically speaking. This is up to you to decide if it makes sense to process those points like other points. You may consider that having twice more points locally is not suitable for example.
    – JRR
    Jan 17, 2020 at 15:44

It is necessary to include overlapping buffers when you process tiled lidar data to avoid edge artifacts. The areas along the edges of the clouds will have distortion when you run various operations (i.e. ground filtering, tree detection, etc..) on them, meaning they can be sources of error. The overlap between the tiles allows for the edges (and the error) to be cropped prior to stitching the tiled data back together.

The rationale for gridding the point cloud in the first place is to break the computational workload into smaller pieces that can be split among cores or machines to speed up processing. The buffers are necessary to ensure continuous "wall-to-wall" outputs (in the form of DEM, DTM, CHM, etc..) when the gridded data are recombined.

In short, you should take the overlapping buffers into consideration when you process your data, but rest assured that including such buffers is best common practice when gridding large las files.

https://rapidlasso.com/2015/08/07/use-buffers-when-processing-lidar-in-tiles/ https://groups.google.com/forum/#!topic/LAStools/fHiXpS1TIzI

  • This does not answer to the question
    – JRR
    Dec 25, 2019 at 2:06
  • Edited for clarity. The buffers are expected and necessary for reconstruction.
    – Kartograaf
    Dec 25, 2019 at 2:19
  • Thank you for your input, however I understand the need for buffers when processing multiple las tiles. I think using buffering during processing is different than inherent overlaps in the data. The former will not produce "double processed" areas, while I am worried that the latter will.
    – Lucas
    Dec 28, 2019 at 12:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.