Repeated range searches & Including in a project

[Rob McDonald]

Paul,

Thanks for the information.

In my own search, I came across nanoflann -- a header-only fork of flann.

http://code.google.com/p/nanoflann/

Although the question of repeated nearby searches remains unanswered, it 
is working well for my needs.

Rob

On 4/15/12 10:11 PM, Paul wrote:
> Hi Rob,
>
> I haven't done anything with libkdtree for a while now.
>
> Have you checked out flann ?
> Its got some heavyweights behind it:
> http://www.pointclouds.org/
>
> cheers,
> Paul
>
> On 3 April 2012 23:00, Rob McDonald <ramcdona at calpoly.edu
> <mailto:ramcdona at calpoly.edu>> wrote:
>
>     I am considering using libkdtree++ for an open source project.
>       Thank you very much for your work and for making this available.
>       Although the mailing list hasn't had traffic since 2010, I'm
>     hoping that someone out there is listening.
>
>     1) I need to do many repeated range searches through a static cloud
>     of points.  Each search will be at a location very close to the
>     previous search.
>
>     Is there a way to return the location in the tree from a completed
>     search?  Then, can that location be passed to the next search as a
>     starting point?  Will this significantly accelerate the search?
>
>     2) What is the preferred way (from the libkdtree developers point of
>     view) of including libkdtree++ in a project?  My project is
>     cross-platform, and uses CMake to generate build files.
>
>     We include some smaller libraries in the project tree directly.  We
>     require the developer to go out and obtain other larger libraries as
>     required.  This can become a hassle.
>
>     I would rather not include everything in our project - the
>     tests/examples, the CMake build files, the Python bindings, etc.
>
>     I believe we could just include the contents of the kdtree++
>     directory in our project.  What other files would be required by the
>     license? What other files would you like to have included?
>
>     3) What is the general status of this library?  Do the developers
>     have any further development plans?  Has this reached maturity?  Our
>     project's needs are modest, so I think we will be fine with
>     libkdtree++ as-is.  At the same time, we haven't committed yet and
>     could switch to another kdtree if that is recommended.
>
>     We will need a range search, but a radius search would be better (if
>     not too expensive).  I saw in the archives some discussion/debate
>     about how best to move forward to support a radius search.  Is there
>     any plan for that?
>
>     Thanks for any information,
>
>     Rob
>
>
>
>
>
>
>     ______________________________ _________________
>     libkdtree-devel mailing list
>     libkdtree-devel at lists.alioth. debian.org
>     <mailto:libkdtree-devel at lists.alioth.debian.org>
>     http://lists.alioth.debian. org/cgi-bin/mailman/listinfo/
>     libkdtree-devel
>     <http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/libkdtree-devel>
>
>

-- 
Rob McDonald, Ph.D.
Aerospace Engineering
Cal Poly, San Luis Obispo
805-756-7242