11

After many readings, I'm still confused about the difference of use and the aims of the following tools for LiDAR data processing and manipulation: LAStools, libLAS, and PDAL.

My understanding so far is that PDAL and libLAS have the same overall goals, and that PDAL is slowly replacing libLAS with enhanced performance and more capabilities. I understand that PDAL is a library that is (and want to be) completely independent from LAStools.

The relation between LAStools and libLAS is the most confusing to me. Are they two completely different separate tools? Does LAStools run on top of libLAS?

Does any of these 3 tools/libraries depends on one another?

Background: I have experience with using LAStools, and have played around with PDAL in the past few weeks.

Edit: From a link comment, I learnt that there is also something called LASlib which seems to be something LAStools runs on. I wish this question can gather a comprehensive overview of these tools for people starting off using LiDAR data and being confused what to go with.

Improve this question
3
  • 1
    From the libLas webpage: "As of 2018, libLAS has been replaced by the PDAL project and it is in hibernation or maintenance mode. libLAS does not provide support for LAS or LAZ 1.4, which PDAL does. PDAL also provides support for many more formats, the notion of PDAL pipelines". So, basically, libLas is deprecated, and being subsumed by PDAL. LasTools I know very little about, as it doesn't play very nicely with Linux.
    – John Powell
    Dec 18, 2018 at 15:14
  • Yes, that's how I figured out the PDAL and libLAS have/had the same goal as libraries.
    – Eskapp
    Dec 18, 2018 at 15:22
  • 1
    The PDAL FAQ also has some comments on both libLAS and Lastools. To summarize, libLAS is basically just for reading the LAS format. PDAL and LasTools are both LIDAR processing toolkits. They are not related.
    – John Powell
    Dec 18, 2018 at 15:43

3 Answers 3

Reset to default
15

The answer by Howard Butler pretty much sums it up. Some more background. When I created the first LAStools and the LASlib library that the tools are build upon I was a postdoc at UC Berkeley and merely needed to prepare LAS files as input for my research on Streaming Delaunay (or Streaming TIN) processing. Because the code seemed useful on its own I zipped it up and published the sources on my Web page in April 2007. It did not have a license because despite having studied Computer Science for 13 years at four different universities I had never learned about how to license source code (Is it on the curriculum at other CS programs?). I was just happy when people used my code. This changed in November 2007 when Howard Butler asked me if he could use LAStools as a starting point for an open source project that would eventually be libLAS.

A few years later - LAStools was more or less a hobby at that point - I lost my job at a high security US lab, was detained for four months in a deportation camp, and eventually deported in handcuffs from the US. This all had to do with my ideas surrounding laser chickens that did not go down well with the nuclear weapons lab I was working at. The "fallout" of this episode set free a lot of energy and resulted in me turning LAStools into a fully featured LiDAR processing suite and LASzip into an industry-strength LiDAR compressor.

In 2012 with LAStools already popular I was able to obtain seed funding from the European Space Agency via one of their Business Incubation Centers. This required me to start a proper company rapidlasso GmbH that would eventually sell commercial and academic licenses to LAStools. At this point LASlib and LASzip also got proper open source licenses (as advised by Howard Butler) which made libLAS somewhat less needed. Then Howard started PDAL (see his answer).

LAStools would probably still be just a hobby project if it were not for US homeland security that keeps you safe from rogue elements like me ... (-; Hope that sheds light from some other angle on the reason why there is LAStools and PDAL and how LASlib, libLAS, and LASzip relate to them.

Improve this answer
1
  • 3
    Had no idea, very interesting insight on the development of LAStools. Thanks to ESA saving this great tool.
    – Mapperz ♦
    Dec 20, 2018 at 15:17
12

libLAS was developed to provide read/write support for LAS and it was modeled on LAStools which at the time was not released under an open source license. In the subsequent years, many parts of LAStools were released under an open source license which negated the need for a parallel effort in libLAS. The library portion of this is called LASlib. Yes, I agree we are terrible at naming things.

PDAL was follow-on from our efforts with libLAS to provide a generic point cloud processing toolkit with a geospatial emphasis (to differentiate it from PCL) that had support for a multitude of formats and provided convenient data workflow and orchestration tools. PDAL is designed to leverage other software (PROJ and GDAL, for example) for things like coordinate system support and vector/raster access. It speaks Python and Matlab in addition to C/C++, and it works on OSX, Linux, and Win64.

In regards to PDAL's relationship to libLAS, PDAL provides full support for LAS (and LAZ) 1.4, while libLAS does not. Someone who needs that bad enough can provide a patch, but PDAL provides a much richer toolbox of functionality than libLAS. If all you need is LAS support embedded in your software, I would look to using LASlib or libLAS if they can work for you. If you want something that could handle nearly any potential geospatial format, PDAL is your choice.

Improve this answer
2
  • So basically as of today, LAStools and PDAL are the two suites of tools of choice to work with LiDAR data, with PDAL going beyond the capabilities of working with LiDAR data only by also supporting other data formats. Did I understand correctly?
    – Eskapp
    Dec 19, 2018 at 15:47
  • 1
    Yeah that's pretty close. LAStools is oriented toward all of the features you can leverage with the LAS format and capabilities needed by aerial lidar processing pipelines. PDAL is more general than that and is oriented toward data abstraction and data processing workflows. As I sometimes say, "PDAL is something you can use to build LAStools", if that makes any sense.
    – Howard Butler
    Dec 19, 2018 at 18:58
1
  • libLAS is deprecated and not maintained. It has been replaced by PDAL.
  • LAStools is not fully open source and (mostly) supports only the LAS format. For the most part it has been created and maintained by a single individual.
  • PDAL is fully open source and supports many point cloud formats, both on input and output. PDAL is modular. It works on OSX, *nix and Windows.

PDAL and LAStools support different algorithms. If you're only using LAS on Windows, LAStools is a viable option if the functionality you need is supported at a cost you're willing to pay. Otherwise, you should look at PDAL.

Improve this answer
3
  • LAStools supports many formats other than .las (.xyz, .laz, .txt; vector formats such as .shp, .obj; raster formats .tif, .asc among others). What did you mean with “mostly”?
    – Andre Silva
    Dec 20, 2018 at 10:36
  • Also, what does “modular” mean? Isn’t LAStools modular as well? And out of curiosity, how many people created and mantain PDAL?
    – Andre Silva
    Dec 20, 2018 at 10:39
  • By mostly, I think he means LAStools does support many other formats, but the point cloud support of those formats is in the context of the "LAS data model". PDAL has plenty of LAS support, but that viewpoint is not pervasive. As for contributors, that can be seen at Github github.com/PDAL/PDAL/graphs/contributors vs. github.com/LAStools/LAStools/graphs/contributors
    – Howard Butler
    Dec 20, 2018 at 14:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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