Boost logo

Boost :

Subject: Re: [boost] new library (space partitioning)
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 2010-07-30 18:29:22

Barend Gehrels wrote:
> Hi Adam,
> First I'm very interested in your library.
> Is it already uploaded into Vault? Could you publish the URL? If you
> didn't upload it already, you might consider to use the Boost SVN
> sandbox instead.
>> I think that the library I'd like to develop don't fit in
>> Boost.Geometry. The purposes of both are different. Space partitioning
>> (in mathematical meaning), is a separate problem. Functionality like
>> this may be used in library like Boost.Geometry but might be used with
>> a large number of different libraries as well. As I see it, it should
>> be a set of general, n-dimensional solutions. Therefore I think, that
>> it should be a separate library.
> I probably agree with this. However, I would like to investigate if a
> coupling of these two libraries is possible, to provide the users of
> Boost.Geometry with a good spatial index which works for them by default
> and which can thus also be used for other purposes.
> So Boost.Geometry might follow your library, or you might use some
> concepts of Boost.Geometry, but I would like to see the sources to say
> more about this.

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?

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.

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.

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 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).


Boost list run by bdawes at, gregod at, cpdaniel at, john at