> On Mar 3, 2015, at 12:13 AM, Even Rouault <[email protected]> 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


_______________________________________________
Discuss mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/discuss

Reply via email to