search

FugroRoames / PointClouds.jl

Point cloud data structures in pure julia
Other
11 stars 1 forks source link

API worries: What should a PointCloud be? #7

Open c42f opened 8 years ago

c42f commented 8 years ago

At the moment it's a table with a spatial index. Ie, each point is a row in the table, and columns are point attributes, which are shared by all points. The spatial index is a KDTree by default.

However, it's not clear

OmriTreidel commented 8 years ago

I think that in some cases a KDTree is not the right choice: for spatial queries it can be significantly faster to have the points in on a grid, and to build a small KDTree for a small number of points in the relevant cells

andyferris commented 8 years ago

Or it's just a table? We pass a spatial index when it's required. Sort of a "lazy" approach to the types.

I plan to look how indexed tables are designed in other packages/languages.

On 24 Aug 2016, at 1:51 PM, Chris Foster notifications@github.com wrote:

At the moment it's a table with a spatial index. Ie, each point is a row in the table, and columns are point attributes, which are shared by all points. The spatial index is a KDTree by default.

However, it's not clear

Whether a spatial index is always required That a KDTree is always the right choice Whether we should just be wrapping an existing table-like data structure (DataFrame? TypedTable? more general abstract table type?) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

c42f commented 8 years ago

Yes, @OmriRoames this is exactly the point: the best index is the one which is specialized to the problem. A KDTree is just a robust default.

@andyferris it might be just a table, and that's fine too (though maybe no point even having this package if that's the case ;-) )

Maybe the answer is "A generic point cloud is an abstract table; a PointCloud is an abstract table which happens to have a spatial index"?

c42f commented 8 years ago

Oops, I think I'm repeating myself here :-)

Should a point cloud also have a bit of extra geometric smartness? For example, if you're transforming the cloud, points, vectors, normals, and general linear forms all transform differently; non-geometric data (intensity etc) doesn't transform at all.

andyferris commented 8 years ago

That's an interesting one... so if we map a Transformation over the points in the table, what happens? Compare syntax:

map!(trans, pointcloud.positions)
map!(trans, pointcloud)

I don't think the former is problematic, per se.

andyferris commented 8 years ago

But that ignores the normals and other geometric stuff.

c42f commented 8 years ago

Yes, not necessarily a problem, unless you have more than one attribute which transforms like position. This isn't inconsistent - eg suppose you cached the neighbour of each point for some reason. Now you have two position-like attributes on each point.

If we did support this, we'd have to be careful to avoid conceptual complexity in the API in the common case that you're not actually transforming the cloud and you really just don't care. (This is the origin of the vector_semantic color_semantic etc in Displaz.jl - it's not fully fleshed out there mind you.)

andyferris commented 8 years ago

(This is the origin of the vector_semantic color_semantic etc in Displaz.jl - it's not fully fleshed out there mind you.)

Oh I see. I guess at minimum we would need "affine spaces" which translate and rotate, "vector spaces" that just rotate, and something that does a similarity transformation on covariance matrices. Since this is expensive a run-time list (a Dict or something) could be used to store the categories. How to work this into an API I have no idea!

EDIT: Also we often store the eigendecomposition of the covariance matrix, so we'd need a one-sided transformation for the eigenvector matrix...

c42f commented 8 years ago

Right. Quite honestly I don't see generic support for spatial transformations being necessary at this stage, I am just speculating.