Friends of LASzip and LAZ, it has come to my attention (from more than one source) that a certain company East of LA has started to more aggressively promote their proprietary LiDAR format known as the „LAZ clone“ (more here, here, here and here but also read the comments) by approaching individual stake holders of the LiDAR community. Trying to convince others to drop support of the open source LASzip compression for LiDAR management, server, and storage in favour of the proprietary „LAZ clone“, said company resorts – if needed – to bad-mouthing the LAZ format with made up arguments that attack the suitability of LASzip for „professional“ use.
It appears the LiDAR lock-in PR campaign is now in full swing despite of my repeated attempts to reach out to said company for creating a joint LAS 1.4 compressor that avoids fragmenting the LiDAR data market. And I may just be hearing back about a tiny tip of the drink-the-koolaid iceberg PR. This seems to mark the start of the „clone wars“ that we at rapidlasso tried to avoid … (-;
One way to engage the Empire is to draw them out from the darkness into full technical transparency. After all, the only argument for why the „LAZ clone“ had to be created was that LAZ lacks a „particular feature“ for efficient employment in the cloud, yet the question what this „particular feature“ was has always been dodged (because we would have happily added it to LAZ).
How can you help?
- Tell us about any „LAZ clone“ campaigs you hear about. Especially those targetting stake holders.
- Attend LiDAR training events and Webinars by ESRI that may be „teaching“ the unsuspecting newbies to lock their LiDAR into the zLAS format as part of a „smart management strategy“ and
– record any arguments made for the „LAZ clone“ or against LAZ so we can publically defute them
– keep them honest by making your unwillingness to drink the koolaid on zLAS known as early as possible.
– ask tough questions and disrupt with a strong technical critique on the user-unfriendly and vendor lock-in nature of a closed proprietary format soon as they „teach“ the LAS to zLAS conversion - Educate folks about the difference between open LAZ and propietary zLAS.
You may comment below (also anonymously) or email us at ‚honestesri@rapidlasso.com‚ if you have any (juicy?) details about „LAZ clone“ campaigns or on video or live training courses where it was „taught“ to lock-up the LiDAR into zLAS during an initial „optimization“ step …
Hey Martin,
This is not about campaigning or the live feeds, but actual experience with zzzzzzzlas
We gave a State a grant to purchase LiDAR for counties that had lots of abandoned coal mines.
The State GIS converted the delivered LAS to ZLAS before putting the data on-line.
A guy in the abandoned coal mine section called me for help – he didn’t have a tile-index, only a fuzzy web image.
Also, the DEMs from the classified LAS were 5-foot ESRI binary grids and too coarse for his needs – 2 or 3-foot would be ideal if the LAS were dense enough. (I experimented and for bare ground with no vegetation, density supported 0.8-foot grids!)
I went on-line and found the ZLAS and got curious so I called the GIS department and was told „ESRI’s going to win the format wars so we adopted ZLAS from the beginning.“
To shorten my story – I spent 2 days downloading data, and 2 days trying to work with ZLAS in Arcmap 10.2.1 to create an index – no good. Nothing in the Help, nothing on ESRI.com, nothing in blogs or user community.
Opened a Support Ticket in mid-September „How to export footprints to a shapefile“
the case was escalated at least once and maybe twice. I spent several hours on the phone while they watched me do exactly what I had already tried with no luck at all.
a week later, I got this e-mail:
„Hello M——,
This is ——- with esri support regarding case #——–. It was a pleasure assisting you yesterday. Like I mentioned on the phone, the mosaic dataset workflow does not work now because the .zlas files are not supported. There is another tool called the Point File Information tool that will generate a polygon feature class for the input las files however, this does not support zlas either. I went ahead and logged an enhancement for this. Here is the reference id and subject line for the enhancement that is attached to this case:
[#ENH-000082178 Enhancement request to support .zlas format in mosaic dataset and tools that support las files such as Point File Information tool.]“
The email had 3 workarounds that didn’t work!
I ultimately used open LASTOOLS, ESRI, and GlobalMapper to make index and smaller tiles (the originals were 16,000 feet by 8,000 feet and unusable) from LAS (converted from ZLAS with ESRI tool).
ummm – ESRI doesn’t support ZLAS… fascinating
Not directly related but someone sent me this link as a track record indicating that ESRI may not be the „ideal candidate“ to bestow new „massive data“ format upon the LiDAR community:
http://www.gisdoctor.com/site/2011/03/10/arcgis-sucks/
I find that I’m primarily concerned with the long term survival of data and its ability to be used in the future. To that end, I’m very reluctant to use data formats that are closed. One of the best things about the LAS format is that it has been described in the open and anybody can create an implementation to use the data in that format. LAZ isn’t quite to the same stage, but it does have a published paper describing the basic approach to the compression and freely available source code implementing it. That means that even if the future brings new CPUs that aren’t compatible with any of today’s chips and the company that created the program may no longer exist, the logical operations necessary to uncompress that data have been laid out.
Unfortunately, I can’t say the same about zLAS. Even now I can’t run the compressor/decompressor on my preferred server architecture. Given the size of lidar files, there is an obvious need to be able to work with them in a compressed form. Given the importance of the data type, I would be remiss if I advocated compression that would only work with one vendor’s software.
Watched the “smart strategies for managing LiDAR data” ESRI webinar and nothing too much mentioned about zLAS advantages over other las compressors. My question why ESRI didn’t want to go with LAZ was just answered with generic not quite compatible or usable with some of the features they want to support. My follow-up question as to why those ‚incompatibilities‘ couldn’t be worked into LAZ as it was offered (as I had heard) was not addressed.
I think the answer as to why there now is zLAS is just politics and large companies that have a big presence in the market can do whatever they want no matter what. It doesn’t really affect any of my workflows, as I usually just work with small datasets, but I’m sure it must be very inconvenient for organizations dealing with tons of Lidar data.
http://xkcd.com/927/
My agency is not going to use a program that doesn’t have a Unix implementation, so zlas is not a solution.
Also, we are just now upgrading ESRI to ArcGIS v10.2 which does not support zlas (must use 10.2.1 or higher).
Additionally, a lot of forums have mentioned that only a small subset of ESRI tools have zlas functionality.
I use Esri products on a daily basis, but cannot for the life of me find a reason to use zLAS. Esri has done so much to move towards open data and standards in the past year. This is such a step back for them and for their users.
I use ESRI products quite a bit too and actually like their Lidar viewer and Profile tool. If their tools would work with laz files, it’d be just great, so what’s the point of introducing zLAS?!?
Absolutely agree with Jarlath here. I too am a daily ESRI user, but the zLAS proprietary format is incredibly unappealing.
Pingback: Digital Geography
How is your claim (that Esri is bad-mouthing the LAZ format) – if true – different from what you have been trying to do?
Whats wrong with promoting your products?
Raghav, I can definitely explain this to you. Are you asking in your role as an ESRI employee?
I am an ex-employee of Esri. Left >year ago.
Pingback: Digital Geography
We only use Unix / Linux / Mac.
Anything that runs just on Windows, to us, doesn’t exist, and smells of decay and lock-in circa the last century.
There’s a lot of high-end tools that only run on windows. Its annoying but slowly getting better as they fade away. Almost always, they are huge monoliths that are too complicated to be ported, and the company has no apparent incentive to invest in the change. Those companies are sitting ducks for agile young startups. Clayton Christianson wrote a good book on this called The Innovators‘ Dilemma.
We refuse to invest in aging platforms that can’t adapt to changing times. If a proprietary system runs only on windows, they are a decade behind, and don’t exist.
Pingback: The LAS format, the ASPRS, and the “LAZ clone” by ESRI | rapidlasso GmbH
As an esri employee who regularly gives free half-day hands on seminars to our users about managing and analyzing Lidar datasets, I never even discuss compression. I don’t discuss esri’s compression technology, and I don’t discuss open source options. It has never been a priority of attendees because we are focusing on products you can create from the data, and how those products can help you make more effective decisions.
There is no nefarious goal on esri’s part. Nobody at esri tells me what to say or how to say it, I just discuss what is relevant to the users, and compression has never been brought up in several years of these seminars.
It is sad that esri is being presented as a company who is doing something to intentionally harm or cause confusion in the geospatial community. That could not be farther from the truth.
I don’t agree with Martin on everything, but this is an instance where our views align. Industry, government, and academia had aligned behind the open source LAZ format. It’s darn good and works well. Esri did their customers and the entire LiDAR community a disservice in developing their own proprietary format. I will continue to use Esri products, but no longer consider it a viable solution for working with LiDAR.
You really confirm our worries. The whole point of this discussion is to assure that LiDAR users world-wide are made aware how they are „locking up“ their data when they are converting it to your employer’s closed compression framework. The fact that you do not inform the (novice) LiDAR users in your „free teaching“ about the important difference of a closed versus an open storage formats shall motivate us to rally even harder against ESRI’s „LAS-washing“ …
We used to be big fans of ESRI. Our experience has ended this. The ESRI team lulled us for two years into believing they would be working with the community and support an open LiDAR compression format in ArcGIS. The very same people that we thought to be having an open discussion with – behind our backs – put together a team that would dissect the open compressor, create some kind of mash-up to include sorting and indexing, contact stakeholders to „prepare them for the new ESRI LiDAR format everybody will be requesting soon“, and went as far as bad-mouth the existing open source solution when trying to convince large agencies to switch from LAZ to zLAS.
It harms the geospatial community when a big corporation uses their market dominance to lock-in data sets as massive as LiDAR into a proprietary format to assure the relevance of their GIS platform in this market. We tried hard to prevent this by repeatedly offering to collaborate and avoid a format war. All the above is unfortunately very close to the truth.
Pingback: ESRI OSGEO Lidar and things • North River Geographic Systems Inc
Pingback: Five Myths about LAS, LAZ, and “Optimized LAS” | rapidlasso GmbH
Pingback: The dArc Force Awakens: ESRI escalates LiDAR format war | rapidlasso GmbH