New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for LAS version 1.4 #591
Comments
@jtfell Welcome to loaders.gl!
The alternative is of course to upgrade the laz-perf C++ implementation and we'd get the JS implementation for free by rebuilding the emscripten library. @hobu Given that you are behind the LAZ-perf implementation that is currently used by loaders.gl:
@jtfell Out of curiosity, do you just happen to have 1.4 files that you wish to load, or is there a specific feature from LAS 1.4 that interests you? Googling, features added with version 1.4 include:
|
Thanks for the in-depth response @ibgreen. We are most interested in the capability to store > 32 classification categories. We also expect to need to deal with existing 1.4 from our customers. There are of course workarounds to use PDAL to downgrade before reading using loaders.gl, but this adds complexity. Is your preference for a pure-js implementation primarily because of the filesize? It would seem a lot more effort to port and maintain a separate implementation rather than making improvements to the existing codebase. I'd be very interested to hear your thoughts on this @hobu |
Well, that certainly used to be the case (I believe the loaders.gl 1.3 LAS module adds 700KB to the JS bundle size). but is no longer a strong reason, since in loaders.gl 2.0 we support dynamic loading of loader libraries from CDN. We haven't configured I would agree that updating the existing C++ code base would seem like the right approach, especially as the new features in 1.4 seem fairly limited. A new emscripten build of laz-perf would be the deliverable that loaders.gl would need. Also perhaps we could add a few test cases to loaders.gl, e.g. a few LAS files with different formats. |
@jtfell Based on your feedback, there seems to be 3 levels of support for LAS v1.4 we could provide in loaders.gl
Presumably in increasing order of effort. Have you tried loading 1.4 files in loaders.gl and confirmed it doesn't work? |
There is a notional roadmap item to add LAS/LAZ 1.4 to the laz-perf library, but because the LAZ encoder changed so significantly from 1.0-1.3 -> 1.4, it is a big lift of effort. It will require porting the new LAZ 1.4 encoder/decorder to laz-perf and implementing the new (wider) types of LAS 1.4 in laz-perf. It is likely to be a completely new API added to the library because of the widening of the types in LAS 1.4. We haven't yet done this because in our experience, we have found that we can work around the need by using LAS 1.3 with the LAS 1.4 extra bytes VLR. This is not a long term solution as more LAS 1.4 content is being developed, especially content with wider types or eVLRs. Another option is to compile the LASzip library itself using emscripten. laz-perf was a reaction to the overly virtual'd design of a previous LASzip version, and with that stuff removed, it is probable that LASzip would compile to WASM with reasonable performance. The library API is quite messy though, and hooking it up to JS will require some shims, shackling, and spackle. |
@sguergachi As you can read above, loaders.gl depends on a web assembly library and there has not been any activity there to my knowledge. I have taken a quick look in the past at implementing LAZ directly in JavaScript but it seemed quite complex and the need simply hasn't been strong enough. Unfortunately, I am starting to suspect that making progress here may require spending some money, i.e. I could put you in touch with resources that do this kind of work. |
Thanks @ibgreen understood this isn't likely to happen. It might be worth indicating on documentation that LAS 1.3 and below is supported, as I only discovered this after implementing a proof of concept in code. |
@sguergachi Good suggestion. Docs updated at https://loaders.gl/docs/modules/las/api-reference/las-loader (and apologies for the wasted time). Just for reference, if someone ever needs support for LAS 1.4 badly enough to consider paying for it, a good option would be working with ActionEngine, they have a team that has been contributing to loaders.gl for a long time. |
From my research there is no pure javascript LAS reader library that can read files in version 1.4 that is open-source. Is developing this functionality on your roadmap?
I can see that your existing parser for LAS files is a fork of plasio which is based on an enscripten build of laz-perf. If you are going to add this, how difficult do you expect the upgrade to be considering that toolchain? If you expect it to not be a major undertaking I could be interested in contributing.
Really, I'm just looking to get the conversation started around this as it seems to be a key piece missing from this ecosystem
The text was updated successfully, but these errors were encountered: