Why did Esri create .zlas compressed LiDAR files instead of adopting .laz?

Question

I am talking about the Esri Optimized LAS file format for compressed LiDAR files (.zlas).

While the uncompressed format (.las) from ASPRS was adopted by practically the entire Remote Sensing and GIS industries (including Esri) and made interoperability among software/platforms an enormous advantage for LiDAR data users, it seems it did not go the same way for compressed LiDAR files.

Is there any technical documentation (from Esri or third parties) comparing .zlas and rapidlasso's early format .laz, which shows advantages from .zlas over .laz?

I am trying to understand why Esri created .zlas instead of adopting the early format .laz (open source).

Answer 1

Esri does support the ASPRS .las format through the latest version, 1.4.

The LAS format is a pretty simple format. It doesn't support indexing or statistics on the data. For instance, the LAS header doesn't include what class codes are in the file. You have to completely scan the file to discover them.

The presenter in the video referenced below mentions that he's seen different separate files used to contain further metadata for the LiDAR data. Because there's no standard for those files, that means that Esri software has to either ignore those files or add support for each version as it shows up.

Esri decided to make an Optimized LAS format which does support lossless compression, re-arranging the structure of the points (for faster retrieval), storage of statistics, etc. There's an API / library available on GitHub under an Apache 2.0 license to help aid adoption by others IF they want to use the ZLAS format.

Note: This answer has been put together from the Esri github repo for zlas and a presentation given at the 2018 Esri User Conference (approximately 40 minutes). I am an Esri employee but not involved in LiDAR support.

Answer 2

I can see no technical reason for ESRI's creation of zLAS. A decision was made that - as far as I understand - was quite heavily contested even within the ESRI management to create a format under their control. There was a big outcry by the Open Source Geospatial Consortium (OSGeo).

At the time a number of misleading statements were circulated that are disputed here. The "LAZ clone" (how I always called it) neither (de-)compresses faster nor is more compact than LAZ. It adds intensity histograms (that should really have been proposed as an addition to LAS to the ASRPS LAS Working Group that ESRI is a member of). It adds an optional point reordering step and integrates a spatial index. All this already existed/exists for the open source LAZ compressor.

I repeatedly tried to get ESRI to the table and work with the community on the open source solution. It happened at the time the LAZ compressor needed an upgrade for the new LAS 1.4 point types anyways. I again and again asked ESRI to tell us what technical features they needed so badly for LiDAR compression, so we could design a joint solution. The frustration of ESRI not even bothering to respond ultimately led to this very successful April Fools Day joke.

---

LAZ has not really changed in response to zLAS. Esri never communicated which ingenious technical detail had made their "LAZ clone" necessary:

1. The intensity histograms were not added to LAZ. This should happen at the LAS specification level to be useful for all. Instead of proposing an amendment to the specification, Esri cooked their own soup. I chose not to repeat this way of acting for LAZ, but continue to encourage Esri to propose this.

2. LASzip is order preserving which allows streaming. The compressor does not attempt to rearrange points for better compression. How to best reorder points is described here and a freeware tool called 'lasoptimize' exists.

3. One thing that "kind of" happened was better API support for spatial indexing with LAX files in the open source LASzip dynamic linked library interface. But this would have happened eventually anyways.

4. What happened as a direct response was a slowdown to the LAS 1.4 design process as I was waiting for Esri to maybe change their mind and cooperate. In the meantime the "LAS 1.4 compatibility" mechanism was added to LASzip to hold folks over.

5. When with 2 years delay due to my pointless waiting for Esri the native LAS 1.4 extension for LAZ was released, it contained zero contributions from Esri. The new "selective decompression" and "variable chunking" features had been been planned before.