CloudCompare forum

Hello,

Currently, geometric features are calculated using a 'Local neighborhood radius'. Are there any plans to extend these calculations to a k-sized nearest neighbours search?

AT

Ah, not particularly... I could still add that to the TODO list, but you would need to wait/find a motivated developer to do it...

Hello,
If it existed, I would also like to work with a defined number of k-nearest neighbors in a given radius. This would be very useful when working with multi-scale detection and would probably reduce the computation time (200 - 400 mio points).

I am also looking for a tool that allows me to compute Statistic features (like mean, standard deviation, medoid) as it is done for Geometric Features. I haven't found a tool to do that yet.

Thanks for reading

DR

Ah, sadly we don't have a routine to extract a neighborhood with the 2 constraints (radius AND knn). This is not impossible to add, but it's clearly a much bigger chunk of work (especially since not a lot of people will dare change this part of the code apart myself - even if they shouldn't be shy :D).

Adding ways to compute the local average and std. dev. would be easy however. I'll add this to the TODO list.

For the medoid, I guess this is where having a maximum number of points would save a lot of time?

Thank you for your answer.

I recognize that my first request with 2 conditions is not simple to achieve if one wants to remain efficient. I've been thinking for quite some time about how to get around this problem, for example by using octree levels (one representative per cell, working with the n³ closest cells (for example 5X5X5 = 125 cells around point)

For the mean and standard deviation it is very nice to add it in the list of todo's.

Concerning the medoid, i assume that it is possible to use it in many cases. Not only to increase the speed of processing (I often work with 400 - 500 mPts) but it is certainly quite effective to help in locating geometric singularities (edges ...)

My point about the medoid was that it's really inefficient to compute on a large neighborhood, hence the need to cap the number of neighbors ;)