First of all, I must explain myself. I walk in here and write that I'd like to desing a library. I don't want you to change something. I'd like to design a library which you might use if you haven't implement some container by yourself. Moreover, I think it should be separate from Boost.Geometry. What do you think about it? Have you any objections? Maby you have some plans and want to do it by yourself? Yes, I think that it is good to be separate, and I don't have objections. What you said, it can be used for non-geometry as well.
And yes, we did have plans, actually we do have a spatial index based on R-Tree which lives as an extension within Boost.Geometry. I don't think it inconvenient to have different (spatial) indexes, I think it is good. However, it would be very convenient to make the interfaces similar (or equal). The interface of the current R-Tree still has to be redesigned so it is not too late, for us.
If no, I think, it's the best to use concepts from Boost.Geometry because it's an existing library. Or to use some adaptor.
Yes, I would advocate using our concepts. The point concept is not complicated and points are easy to implement and adapt to our concepts. The point you have in the library I saw last week can be adapted as well.
But the most important thing is that if you want to make building of arbitrary kd-tree possible boost::geometry::point should provide a method returning given coordinate not in compile-time.
See also Luke's response on this. We have compile time access to select by coordinate index but, of course, you could add a wrapper in between translating from runtime to compiletime.
Still, it is possible to create kd-tree using coordinates indexed in compile-time and I don't know if it will be a lot worse than the other possible trees. The problem may occur for volume objects.
I think it would be good.
I might implement simple version of kd-tree for points using your interface and show it to you if you like.
Later I'd like to use adaptors and to implement some tree building traits. Different building algorithms might use different interfaces (compile-time or not). We have for several free functions also different internal algorithms, which can be specified as an extra argument. We call that a strategy,
Yes, I would like that :-) there are concepts for different strategies (distance etc.). You might look if such a system would be convenient for you as well. Regards, Barend