Re: [LAStools] Modifying laszip API

[Martin Isenburg]

Hello Andrew,

So I assume you are not talking about the LASlib library where this is already supported here:

http://github.com/LAStools/LAStools/blob/master/LASlib/inc/lasreader_las.hpp#L61

but rather the C interface of the LASzip DLL where currently only this open call exists that accepts a const char* pointer to the file name:

http://github.com/LAStools/LAStools/blob/master/LASzip/dll/laszip_dll.h#L424

so you are suggesting to create a second open call with a void* as input (that is understood to be a pointer to an open and ready to read from class of type ByteStreamIn) in order to hide the std::stream from the C DLL API? You would then simply create such a ByteStreamIn class using this constructor here:

http://github.com/LAStools/LAStools/blob/master/LASzip/src/bytestreamin_istream.hpp#L46

and pass a void pointer to this one to the LASzip DLL? Mmmm ... certainly an easy fix. But it requires some "under the hood" knowledge to correctly use the API exposed by laszip_dll.h ... Does anyone have a better idea how to allow the current C DLL API of LASzip to start reading from a std::stream?

Regards,

Martin @rapidlasso

On Mon, May 2, 2016 at 5:49 PM, Andrew Bell <andrew....@gmail.com> wrote:

I'm wanting to modify PDAL to use the laszip API, rather than the old LASzipper/LASunzipper interface that is currently in use.  In order to do so, I need to modify the API to support accepting an open stream rather than a filename on open since we have to deal with LAS files embedded in other files rather than as standalone las/laz.  This seems rather straightforward using ByteStreamInIstream, but I need to be able to pass an open std::istream pointer through the API to the ByteStreamInIstreamXX constructor.  It seems that the interface is a C API and won't support passing a std::istream pointer to the code that does the actual processing.  Is this correct?  Can/should I cast the std::istream pointer to a void pointer?  Other ideas?

Thanks,

--

Andrew Bell
andrew....@gmail.com

--
Download LAStools at
http://lastools.org
http://rapidlasso.com
Be social with LAStools at
http://facebook.com/LAStools
http://twitter.com/LAStools
http://linkedin.com/groups/LAStools-4408378
Manage your settings at
http://groups.google.com/group/lastools/subscribe

[Evon Silvia]

I see two options off the top of my head.

1. Overload laszip_open_reader with a function that accepts an open std::stream object, a function pointer callback, and iscompressed(bool). The callback function should accept a laszip_point*. Internally, LASzip would create a reader object and add laszip_read_point(reader) to the list of std::stream callbacks when data is ready to be read. That way laszip_read_point can be called asynchronously. Once the point is read, LASzip passes it to the callback function that the user provided, value 0 if it failed. It's then up to the user to collect the points that are being read.
2. Alternatively, overload laszip_open_reader with a function that accepts a laszip_POINTER reader, std::stream pointer, function pointer callback, and iscompressed(bool). LASzip could internally cache the point data from the std::stream in memory, then pass the N number of points available for reading to the user's callback function. It's then up to the user to call laszip_read_point in the callback function N times. That would be more similar to the current interface.

I'm not familiar enough with the ByteStreamIn interface to know which would be simpler to implement.

Evon

[Evon Silvia]

...either way, since the LASzip C DLL doesn't directly support a signal-slots mechanism, I see having the user pass a function pointer as being the most convenient way to "trigger" the availability of more points, while giving the user full control over how those points are handled.

Evon

[Andrew Bell]

On Mon, May 2, 2016 at 1:50 PM, Evon Silvia <esi...@quantumspatial.com> wrote:

I see two options off the top of my head.

1. Overload laszip_open_reader with a function that accepts an open std::stream object, a function pointer callback, and iscompressed(bool). The callback function should accept a laszip_point*. Internally, LASzip would create a reader object and add laszip_read_point(reader) to the list of std::stream callbacks when data is ready to be read. That way laszip_read_point can be called asynchronously. Once the point is read, LASzip passes it to the callback function that the user provided, value 0 if it failed. It's then up to the user to collect the points that are being read.
2. Alternatively, overload laszip_open_reader with a function that accepts a laszip_POINTER reader, std::stream pointer, function pointer callback, and iscompressed(bool). LASzip could internally cache the point data from the std::stream in memory, then pass the N number of points available for reading to the user's callback function. It's then up to the user to call laszip_read_point in the callback function N times. That would be more similar to the current interface.

Thanks, but this is more than I need.  I only need to call an equivalent of laszip_open_reader with an open std::istream pointer instead of providing a filename.  The method for reading points as it exists is fine.  My confusion/problem is the interface, which appears to support C and not C++ which therefore makes using a std::istream pointer impossible.  Should there be a C++ interface as well as a C interface?

--

Andrew Bell
andrew....@gmail.com

[Martin Isenburg]

Hello,

currently there is no C++ interface for the LASzip DLL. However, you could use the LASlib library and given that your PDAL source is open I think you can also just link to that code without violating the LGPL. As this may not work - license-wise - for closed source PDAL derivatives you could probably compile your own LASlib C++ DLL without much trouble. The class EXPORT hooks are more or less already there but I have not yet used them myself. 

Regards,

Martin

--

--
You are subscribed to "The LAS room - a friendly place to discuss the the LAS or LAZ formats" for those who want to see LAS or LAZ succeed as open standards. Go on record with bug reports, suggestions, and concerns about current and proposed specifications.
 
Visit this group at http://groups.google.com/group/lasroom
Post to this group with an email to las...@googlegroups.com
Unsubscribe by email to lasroom+u...@googlegroups.com
---
You received this message because you are subscribed to the Google Groups "The LAS room - a friendly place to discuss the LAS and LAZ formats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lasroom+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Howard Butler]

> On May 6, 2016, at 4:14 PM, Martin Isenburg <martin....@gmail.com> wrote:
>
> currently there is no C++ interface for the LASzip DLL. However, you could use the LASlib library and given that your PDAL source is open I think you can also just link to that code without violating the LGPL. As this may not work - license-wise - for closed source PDAL derivatives you could probably compile your own LASlib C++ DLL without much trouble. The class EXPORT hooks are more or less already there but I have not yet used them myself.

Martin,

It will be possible to satisfy the LGPL linking scenario without mixing any LASzip code into PDAL's codebase and causing any license pollution.

As I've mentioned before, we also have the lazperf library [1] available, which is what we use to provide LAZ support in JavaScript and C++. It provides an alternative implementation to the laszip.org library. We have no reason to get in front of what you're planning for LAZ 1.4 with it, but lazperf does have a significantly different software engineering perspective than the laszip.org codebase. There is also a significant regression test suite to ensure that we maintain compatibility with your leading codebase. See https://travis-ci.org/hobu/laz-perf for output. I appreciate the specification document [2] and I hope that effort can continue.

For the moment, PDAL is considering defaulting to using lazperf so we only have to worry about one codebase. We're already having to change APIs due to the deprecation of the LAZunzipper API. Lazperf fits PDAL's C++ better than the LASzip DLL API, and PDAL already uses Lazperf for compressing individual attributes without LAZ-style models in drivers such as Oracle and SQLite and over-the-network requests like Greyhound. Multiple libraries are confusing for our users, especially since we are not doing sophisticated things beyond simple reading and writing data. Our plan is to catch up the Lazperf codebase with a follow-on implementation of 1.4 once your specification document is released and enough compatibility test data is available to do byte validation on more than one implementation.

Howard

[1] https://github.com/hobu/laz-perf
[2] https://github.com/LASzip/LASzip/blob/master/design/specification.rst