4

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).

  • It seems as if the FAQ answer is the only one you're likely to get which isn't opinion-based – Vince Sep 6 '18 at 22:36
  • That FAQ only explains .zlas. It does not say anything about .zlas in comparison to .laz. – Andre Silva Sep 8 '18 at 12:23
2

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.

  • 1
    Some of your assertions are entirely incorrect. Whereas there is not compression, per se, in the LAS format it is a binary format and is quite standardized. I was on one of the LAS format committees and we made very specific decisions that, at the time, supported industry standards, developer and open source communities. The attribute fields have very specific and clearly defined domains. For example class can only have specific text assigned making it so a developer does not need have metadata embedded in the actual file. – Jeffrey Evans Sep 7 '18 at 17:06
  • Okay, but there's various types of compression. How about I reword it as "adaptive compression"? On the attribute fields/classes, if there's not an index or info in the header on what attributes are present, how is my statement (scan the whole file) untrue? – mkennedy Sep 7 '18 at 17:21
  • Thanks. It helps understanding what the .zlas format is (and its open source library) and its advantages to ASPRS .las (+1). On the other hand, my question is about .zlas and .laz. What are the technical advantages/differences from .zlas to the early format .laz?. The .zlas format does a lot of things (as stated in the lecture) but I'd like to know what it does that .laz doesn't, etc. I think probably there must exist significant differences? Is there any technical material comparing them? – Andre Silva Sep 7 '18 at 17:50
  • 1
    There is no open source software that supports zLAS. There is only a free-as-in-beer binary SDK available. – Howard Butler Sep 8 '18 at 21:22
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.

  • 1
    It's helpful to know the history in this from rapidlasso's/open source community's POVs (+1). About .zlas "...neither (de-)compresses faster nor is more compact than LAZ": is there any technical documentation showing such results? Has anybody already done such tests and documented them? I'm also interested to know more about which features the .zlas format initially had that was posteriorly incorporated in .laz. You mention a little bit about these in the answer and in the 'myths' post, but, can you elaborate? Include a list (and description) about all these features? Thanks. – Andre Silva Sep 16 '18 at 14:12

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.