6

Compressed LAS pointclouds (LAZ) are significantly smaller than the uncompressed ones (I observe a compression factor of x4 - x5). Since point clouds are often large files, this is a substantial advantage (for disk space, bandwidth, ...) and the compression is lossless. Yet I still see LAS data being processed, stored and distributed mostly in the uncompressed .las format.

I am wondering: Does the computational overhead justify this? Or are there other good reasons?

Improve this question

2 Answers 2

Reset to default
11

Although I personally didn't feel a major difference in speed, apparently there IS a major increase of read and write time when using LAZ. Once again the lidR doc is an excellent source of information on the topic (in this vignette):

We can therefore speed-up the computation time by a factor of 2 by using the las format instead of laz. Obviously the gain is less significant for more computationally demanding processes.

So for faster computation users can opt for las files instead of laz files. Obviously, there are good reasons to use laz files instead of las files. The strong compression brought by the laz format has a lot of advantages for storing data. It is up to the user to choose a format by considering the trade-offs between space and computation time.

In actual computational tests (chm <- rasterize_canopy(ctg, 1, p2r())) further below in the vignette, they demonstrate a factor x4 between las and laz.

It also elaborates a bit on las-indexes (.lax), which apparently can have a similar impact on computation time (factor x2 at the cost of one-time processing time to create the index and the negligible storage space for the .lax file [>0.1% of the point cloud storage space in my experience]).

So for me personally, I conclude that

  • for distribution and archive, .laz should always be the format of choice. LAStools laszip offers a quick way to compress.
  • data, that is often and actively processed, quickly justifies storing the decompressed .las files for significantly faster computation
  • LAS-indexes (.lax) are always a good idea (little addition of storage for significant boost of computation time), as soon as you process your data more than once and of course only if your processing tools support them (lidR and lastools do, for PDAL I don't know).
Improve this answer
4

@Honeybear's answer is the right one, but with one important caveat – use LAS if you need to touch all of the points. If you don't need to touch all of the points, LAZ-based COPC can be much better.

COPC is an LAZ file with internal .lax -like index that some tools like PDAL and laspy can take advantage of to only read all of the points in a given window or read points that only meet a specified resolution spacing. They can even do it over the network, and they can be read like normal LAZ files that are not enhanced to leverage the index. I wrote more about what COPC is in this Lidar Magazine article.

Improve this answer
2
  • Nice, thanks for the addition. A fried recently told me about COPC, cool to see it mentioned here as well. Performancewise I'd assume it to be similar to LAZ+LAX (when processing all points)... or is there additional overhead that'd justify not using it vs. LAZ?
    – Honeybear
    Commented May 31, 2023 at 9:58
  • 1
    The only significant overhead penalty of COPC is that for files that have GPSTime in them, there is about a 10-30% storage efficiency penalty due to the coherence disruption of spatially ordering the points instead of temporally ordering them. The tradeoff is that with COPC you aren't likely to slurp all of the bytes over the network most of the time anyway, and so the penalty doesn't matter in most usage cases.
    – Howard Butler
    Commented Jun 26, 2023 at 20:15

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.