[OSGeo-Discuss] The LAS format, the ASPRS, and the “LAZ clone” by ESRI

[Howard Butler]

> On Mar 3, 2015, at 12:13 AM, Even Rouault <even.rouault at spatialys.com> wrote:
> 
> Hi Cameron,
> 
>> It is difficult for OSGeo to stop a vendor from promoting their product,
>> or promoting a specific lock in strategy.
> 
> Of course. That was exactly my point.

OSGeo can wag its finger at people and say "drugs are bad" all it wants, but that isn't going to change the outcome in any substantive way. The reality is if zLAS is more convenient for its users, and it is better than open alternatives like LAZ, people are going to use it. On technical merits, it might be that zLAS is marginally better than LAZ in some situations, but LAZ can still evolve if people put the resources into it. On the ecosystem merits, it might be that zLAS is super convenient for Arc* users who don't want to ever tread outside their gated community. Whatever the reasons, zLAS will or won't gain traction based on the marketplace determining its usefulness -- not organizations like OSGeo or even ASPRS crying foul.

The only worthy nit to pick is with zLAS's name being derived from or similar to the ASPRS LAS name. Whether intentional or not, this implies some kind of relationship between the two things. If ASPRS is to make that complaint, however, ESRI can rightly point at LASzip (but not LAZ) for the same name-confusing infraction. 

Personally, I'm extremely skeptical. LAZ has tons of uptake, there's already a ton of data available in the format, and pretty much every significant point cloud/LiDAR software out there *besides* ESRI implements at least read support for it (using the laszip.org codebase). Any other compressed point cloud format would have to be many *times* better than LAZ to be closed and overcome it. A few percent better isn't going to matter. 

The situation is way better than it was in the geospatial imagery space say 15 years ago or even today, where closed commercial formats still control much of the market.  LAZ has commoditized the fat part of the point cloud compression market so effectively that there is little headroom for a commercial approach to operate except for strategic situations like zLAS. In my opinion, zLAS is a canary indicator of the success, not failure, of LAZ. It's an attempt by ESRI to innovate in an area that matters to its users in a way that serves ESRI's business interests.  Everything else that's interesting is already covered by LAZ.

LAZ has had very few resources put into it. Martin Isenburg developed it, and I helped to license it, package it, and release it as an open source library. Beyond that, no significant institutional support has come along to support specification development, to support standardization, or even to pay for new features like alternative spatial organization like zLAS supports. If the community values these things, it needs to pay for it or start putting in the time/effort to make it happen. Thus far, it hasn't.


>> But we can:
>> * Support the OGC in developing an OGC standard for LiDAR. Once a
>> standard is in place, there is a much stronger reason to make use of
>> that Open Standard. In particular, many national government agencies
>> have policies which promote standards over proprietary interfaces.
> 
> With my mostly uninformed eyes in that topic, I don't know if OGC is the most 
> relevant organization in that matter. It seems that the ASPRS would be a more 
> natural host as it has already published the spec of the (uncompressed) LAS 
> format:
> http://www.asprs.org/Committee-General/LASer-LAS-File-Format-Exchange-
> Activities.html

As Michael mentioned, ASPRS is poorly suited for development of technical software specifications. There is no standard ratification procedure, no procedural way to resolve disputes, no typical standards-body IP protections, and no rules to ensure the playing field is even from the start. Of course, the ASPRS LAS committee can say, "go use E57, which is lives inside ASTM and has all those operational features you request," but very few softwares use that format. LAS was there first and it was good enough. It's neither the best nor the easiest to use, and it doesn't cover the problem of point cloud data transmission most generically or efficiently. It covers the problem well enough, and it has wide support in a number of softwares (sales pitch: even in your browser with http://plas.io !). It's going to be around for a llllooonnnggg time, and shapefile or GeoTIFF are prefect comparisons. 

> I'm not sure about the LASzip format however, the compressed one, which is the 
> one that ESRI has "cloned" into zLAS. I skimmed through http://www.laszip.org/ 
> and couldn't find a reference to something more formal than LGPL code that 
> implements it ;-)

There's actually two implementations now, though the second implementation https://github.com/verma/laz-perf is derived from the original LASzip codebase. The second, which my company developed, allows LAZ to work in Javascript in addition to C/C++ (for http://plas.io and now http://potree.org), and it has a substantial test suite that could be considered "conformance tests". The real specification of how the format should be written is still the LASzip software at http://laszip.org however. I discussed the challenges of all this at https://groups.google.com/d/msg/lasroom/a42rWaPJJh4/sAy-4rc3if0J for those interested in reading more.

Martin and I chose the LGPL license for LASzip to prevent a commercial player from disrupting the format, which was only specified in software, with slightly incompatible-but-same implementations of LAZ using the LASzip software itself. It doesn't have the stability of a full specification, or the institutional heft of a ratified standard, but it was enough protection to get it off the ground without it collapsing on itself. Is zLAS is a manifestation of ESRI's frustration, fear, and/or incompatibility with working within the ground rules of LGPL software? Or is it ESRI trying to exert its monopoly power in desktop GIS into a domain (point clouds, LiDAR) in which it has a weak foothold? Conveniently both, I would think.

The solution to prevent uptake of things like zLAS is investment in open stuff like LAZ -- not complaining about zLAS. Demonstrate its folly to users who try it by making LAZ so much better and useable in places that zLAS can never play (for the third time, go see LAZ in your non-mobile browser by choosing one of the files in the Browse drop-down at http://plas.io ). Make its features match or beat the purported features of the closed formats. Specify and standardize its implementations to satisfy those who require such efforts. Institutions that value open data need to invest at the software level to keep it open. It doesn't just happen on its own.

Howard