First working version.

[evetion]

No description provided.

[evetion]

@visr @c42f In your opinion, what is the best way to come to a generic point cloud type? We're now exporting header and a vector of a specific pointtype. Laszip itself also has a different pointtype and the library you're using probably expects another type. Do we want a Cloud library?

And do we want some streaming possibilities? I'm also thinking about using LasIndex, or creating an index myself. Should this be a separate library, or be integrated into the cloud library?

[evetion]

Ah, I missed this conversation here:
visr/LasIO.jl#4 (comment)

[c42f]

I think we do need some data structures for storing point clouds in memory, but it has so many commonalities with the tooling needed for working with general tabular data that we should use that upcoming tooling if possible. We built a lot of internal tooling for point clouds at FugroRoames. To cut a long story short, we ended up using something along the lines of @andyferris'sTypedTables package, with some special purpose spatial indices.

I think this was the right choice: a point cloud is just a special case of a tabular data structure (think DataFrames), but one where it's rather critical to have type stability. One may view this kind of data structure either as a Tuple of heterogeneous columns (ie, point attributes) or as a Vector of rows (ie, points). Either of these data layouts can be beneficial, depending on your use case.

For now, since LAS has a fixed number of point formats (not including extra data bytes...), I'd just define a struct for each of them in the low level IO libraries. Providing a way to read a single point or small number of points on demand then gives a simple streaming interface. Worry about the "one true data structure" for point clouds later IMO - defining general type stable tabular data structures is a problem which seems simple, but is really difficult :-)

By the way, it's really great to see a wrapper for liblaz!

[andyferris]

Yes, agreed. These day's I'm thinking it's more constructive to think of pointclouds (or tables) as collections of points (or rows) which may internally use row- or column-based storage, or in this case might correspond to a memory-mapped file that is read on demand (and on disk might be more bit-packed than the Julia struct).

It's not too hard to use NearestNeighbors.jl with such a structure, so long as it presents itself a bit like a Vector{Point} (for some Point).