working with multi-temporal data

[wiesehahn]

I was just wondering what happens if we are working with multi-temporal data.

It might happen that we want to work with data which has the same spatial extent but originates from different acquisition dates. While I think this was no major use-case in the past it might be more important in the future with increasing data availability.

We can potentially put the data in one folder or VPC and run some pipeline on it (although I have the feeling this might not be the best idea). I havent tested it yet but I could imagine that this might be problematic as tiles are processed with a buffer and there are multiple neighbouring tiles (from different times). Or is this somehow handeled with datetime as kind of a temporal index?

[Jean-Romain]

There is nothing done on this aspect. Neither in lasR nor in lidR. Both are processing the files provided by the users. This this the responsibility of the users to provide a set of files that make sense for them. While I can maybe provide helper tool to filter data I don't see what I could do more. I won't prevent processing files with different dates. Especially dates are usually incorrectly registered so it will lead to false positive.

The case you are describing is a cases with overlapping tiles ans is badly handled by defaul by lidR and lasR and very likely other software as well.

What kind of tool would you expect?

[wiesehahn]

I mean if there are overlapping tiles for example from two campaigns and we put them in one folder/VPC which we use as input for execution we might have a problem if a buffer is read and processed automatically. There are always two different files with the same spatial extent which could be used for the buffer. I was wondering how the algorithm chooses which of these tiles to use for buffering? Is it the first by name?

I guess correct in most cases would be to choose the tile which has the same or closest acquisition time (we have this in VPC already). Otherwise possibly a warning either if creating VPCs with overlapping tiles or at exection?

While this use-case (simply creating DTM/CHM from multiple tiles with overlapping extent) is possible it might be handeled better if we split files in multiple folders/VPCs before and execute the pipeline on each seperately.
But I could also imagine some advanced use-cases in the future where we would want to process multi-temporal data in one execution. E.g. to coregister pointclouds of t1 and t2 and store differences of canopy height to disk.

[Jean-Romain]

The tile used for buffering are based on spatial analysis. For the current processed tile/chunk we take its bounding box, buffer it by e.g. 20 m and perform a spatial search of the other tiles that overlap the buffered bounding box. In the case of overlapping tiles this means that the two overlapping tiles will be loaded together and processed twice. The dates are non-read metadata (often set to zero anyway) that we do not use at all. It is all based on spatial analysis (maybe I should make a sketch?).

So if you put your 2018 and 2023 data together in the same folder or in the same VPC collection, things will go wrong for sure. In lidR and lasR a file collection is considered as one single massive point cloud processed by (buffered) chunks. The confusion is that chunks usually correspond to files because this is the most obvious chunking pattern. But we are not processing files but rather we are processing one massive point cloud that appears to be already physically chunked in files.

If your files overlap, then, this is the default chunking strategy that is invalidated and you should rather define another chunking strategy.

I guess correct in most cases would be to choose the tile which has the same or closest acquisition time (we have this in VPC already). Otherwise possibly a warning either if creating VPCs with overlapping tiles or at exection?

lidR already has a warning that nobody is reading. I will add a warning in lasR as well, this is planned. Yet it won't help much in my opinion.

While this use-case (simply creating DTM/CHM from multiple tiles with overlapping extent) is possible it might be handeled better if we split files in multiple folders/VPCs before and execute the pipeline on each seperately.

Sure you must execute each separately. As mentioned above, the input is considered as one (massive) point cloud. If it is actually two point clouds then is should be two datasets.

But I could also imagine some advanced use-cases in the future where we would want to process multi-temporal data in one execution. E.g. to coregister pointclouds of t1 and t2 and store differences of canopy height to disk.

This is a completely different use case that is not supported. I'm not excluding to add a capacity to deal with 2 point clouds simultaneously but this not a feature that I will add without founding. This is a big project.

[wiesehahn]

It is all based on spatial analysis

This is the only thing I dont understand, if there are multiple files with the same spatial extent we cant choose which one to use as buffer just based on its extent, either one has to be chosen (random, by name, by date, ...) or we take both and use something like mean (which would not make sense).
But probably it doesnt matter as pointclouds should be processed seperately.

[Jean-Romain]

Let say that files A.las and B.las are overlapping with the same extent e. We are processing file A. To process file A, we also look at the files that overlap the bounding box e + buffer. This include the 8 surrounding files but ALSO the file B.

When processing A.las you also load a portion of the 8 neighbor files to get a buffer + the file B.las that is also within e. So file A and B are read and merged together as a single point cloud.

Now assume that the entire dataset has duplicated tiles then the buffer will be made created out of 16 files instead of 8.

Why? Because it is not the file A that is processed but the region/chunk e and the chunking pattern of the dataset is invalid: two files are mapping the region e leading to weird behavior. This is exactly the same in lidR. Both software are designed to processed cleanly tiled dataset. If your dataset is not "clean" then there are an infinite number of special case to deal with. This is not manageable.

The most common case of overlapping tiles is when the point cloud inside a file is not rectangular but slightly rotated and sheared (likely after re-projection). The bounding boxes recorded in the header being rectangular the files seem to overlap when you read the header but if your read all the point it is actually a continuous dataset without overlap. In this case the bounding boxes of the files do no match the shape of the point cloud inside each file and this is a problem because it provide the false information that the tiles are overlapping and the chunking pattern is messed up. In this case either in lidR or lasR can chunk by 1000 m instead of chunking by file since the file pattern is incorrect.

Sometime a dataset have files that are already buffered.

Sometime a dataset looks good but some region are duplicated for unknown reason. Is it another flight-line? Is it a duplicated file? Is is something else?

Sometime files are flightlines

Sometime users want to process two overlapping dataset from different years.

There is no way to predict and handle all the possible cases. There is a part of responsibility from users to get their data tidy. The cases with already buffered tiles and files are flightlines are the only cases that could, more or less easily, be handled automatically.

If you need to retain only one thing: lidR and lasR are processing sequentially chunks/regions. The chunks should be contiguous and non overlapping and the point cloud should be one clean point cloud. The files do no matter much, what matters is the entire point cloud. Problems arise when files do not correspond to clean chunks and when files do no contain a clean point cloud (e.g. duplicated points in multiples files). Btw this is also true for LAStools.