Paul RamseyThe availability and use of LIDAR continues to grow and has become a vital source of spatial information. More and more organizations are collecting LIDAR, processing it, and sharing it. Like vector and raster GIS data, it is becoming an important piece of public information, and interoperability is a key concern.

Fortunately, there has been a standard format for some time, the “LAS” format, and an open source library, “libLAS”, that can read and write the format.  Rather than write their own format support, most vendors have simply used libLAS, and LAS has become an industry standard.

Story over, right? Thanks to open source, the usual decade of broken interoperability in a new data field has been avoided and LIDAR users can get down to the important business of working with their data.

Not so fast!

LAS format is not without its drawbacks:

  • While it is a binary format and does not waste any space unnecessarily, neither does it apply any compression to the data it stores. That’s not good for archival use.
  • Also, LAS stores points in scan order, so accessing any particular chunk of points involves reading the whole file. That’s not good for random access.

Clearly there is a little more work to be done. Can LAS be improved? In fact, it already has been:

  • An open source compression library LASzip can apply 20:1 lossless compression to LAS files, making them great for archival purposes.
  • Other LAS users have experimented with re-ordering points in a LAS or LASzip file to allow random access to internal chunks of the LIDAR point cloud.

Basically, making LAS smaller and faster is not rocket science, and if the work were incorporated into libLAS then the whole LIDAR community could leverage it together, and the user community would only have one file type to interchange.

Work together or build your own?

Now, if you were a leading software vendor with a dominant position in the vector data space, a passable position in the raster space and a weak position in the LIDAR space, how would you approach LIDAR support.  Would you:

  1. Approach the libLAS community and indicate your interest in collaborating to improve LAS for better compression and random access?

  2. Build your own proprietary compression and random access routine, release it in binary only form, and avoid supporting the existing open source approaches?

Enter zLAS

If you chose #2, congratulations, you own a huge chunk of southern California agricultural land outside Redlands.

Rather than avoiding a lengthy LIDAR format war, we are now entering one. In some respects, this will be healthy: the open LAS community now has to come up to feature parity faster than it might otherwise. But in most ways, it’s unhealthy: users will have data interchange issues, they’ll have to understand and install format translation software, and add extra steps to their processing chains. The only people who really win here are the those in the format translation business.

What can be done?

Boundless will work with the libLAS and PDAL communities on bringing random access and compression into the open source world.  We’ll encourage our customers to keep investing in improving the software commons.  And we’ll keep on murmuring quietly to ourselves, as we walk down the street: open standards, open data, open source. There’s no better way.

OpenGeo Suite 4.0 supports many LIDAR formats, including LAS, LASzip, Oracle Pointcloud, PostgreSQL Pointcloud and more.

10 thoughts on “Format Wars Episode V: LIDAR

  1. You might be interested in the SPD format, it’s an open source LiDAR format, capable of handling full waveform data and storing data compressed and spatially indexed. It’s built on HDF5 so files can be read / written to without the SPD library. More details are available at and two papers in Computers & Geosciences.

    1. I was about to mention SPDlib too! Compresses well, and supports spatial indexing. As a user, the spd* command line tools (similar too gdalwarp & co.) are very valuable too.

  2. I am so disappointed by this internecine warfare fueled by short term commercial horizons, In my view (I have been practicing this since the early 1980’s) openness and archival future forwardness are the only way to go. I have CD’s and DVDs and tapes with multiple iterations of the same models of London that I and colleagues created (1987, 1996, 2002). Each good in its time. Each obsolete, because founded in proprietary and now obsolete software. Without a future focused translation software that is proprietary neutral I continue to despair. I will continue to advocate ASCII printouts till that day (VRML, X3D etc).

  3. This is not new in the LiDAR world. Another violator is Mr and Mr Bentley with the Pointools POD format. If the “standards” don’t perform, then every major company, from Alabama to California, will choose #2.

  4. The costs of not having standards, and/or not using them, are high. This kind of short sightednes might earn a few claps around the different ESRI conferences when presented. It might even convince the different speakers that this was indeed a good idea. But in the long term this will not serve customers nor others. I remain a reluctant fan and user of ArcMap from ESRI. But their stance towards standards has a chilling effect on my ever fading enthusiasm for them.

  5. As for Hexagon Geospatial (formerly ERDAS and Intergraph software’s), we tuned up our tools to read and write LAS fast in a both random and sequential and are doing the same with LAZ. We did create a Level of Detail format to support rapid zooming in and out of LAS and LAZ files. It uses an HDF approach of storing multiple LAS files, a spatial index and point statistics to help with fast and accurate color ramping.

Leave a Reply

Your email address will not be published. Required fields are marked *