type, summary changed; keywords set

awulkiew — Wed, 13 May 2015 13:18:53 GMT

keywords rtree serialization added
type Bugs → Feature Requests
summary More useful rtree API → More useful rtree API (public apply_visitor, ...)

Unfortunately I plan to change the internals: simplify it, support more lightweight type of nodes, serialization and persistent memory. They are not ready for making them public.

AFAIU what you want to do would be to save the whole rtree into the database. So basically what you need is the serialization support. I started working on it using Boost.Serialization, are you familiar with it? Would it be possible to write a custom Boost.Serialization Archive for your database in case if the serialization was supported by the rtree? Maybe would you like to finish the Serialization support and contribute it to the Boost.Geometry? I stopped at some point because I realized that I should use a different approach.

For now you could of course use the details but have in mind that in the future they can be changed, though probably to something similar. Basically you could use the interface which is there for the experimental Serialization support so:

enable it by defining BOOST_GEOMETRY_INDEX_DETAIL_EXPERIMENTAL
use detail::rtree::private_view<rtree> and detail::rtree::const_private_view<rtree> to access depth and apply_visitor

If you had any problems the Boost.Geometry mailing list is a good place to ask questions.

Thu, 14 May 2015 10:11:27 GMT

I don't know much about boost serialization but I don't think it can help me. The database I am writing to has a certain format given by consortium which I have to follow. And it's not a 1:1 match with rtree nodes f.e. I have to serialize several nodes into single database blob but when the blob exceeds a size limit I have to allocate another blob and then nodes in the first blob change their types to be able to reference child nodes from different blob. So I really need access to individual tree nodes and custom visitors to do the transformation.

My motivation for using geometry::rtree was that I get properly balanced r-tree with optimal depth so I don't need to hack r* algorithm myself. I didn't know it is being reworked. Anyway thanks for bringing this library into boost. I am confident it will evolve into something useful also for this type of usage. It's just not there yet.

Replying to awulkiew:

Unfortunately I plan to change the internals: simplify it, support more lightweight type of nodes, serialization and persistent memory. They are not ready for making them public.

AFAIU what you want to do would be to save the whole rtree into the database. So basically what you need is the serialization support. I started working on it using Boost.Serialization, are you familiar with it? Would it be possible to write a custom Boost.Serialization Archive for your database in case if the serialization was supported by the rtree? Maybe would you like to finish the Serialization support and contribute it to the Boost.Geometry? I stopped at some point because I realized that I should use a different approach.

For now you could of course use the details but have in mind that in the future they can be changed, though probably to something similar. Basically you could use the interface which is there for the experimental Serialization support so:

enable it by defining BOOST_GEOMETRY_INDEX_DETAIL_EXPERIMENTAL
use detail::rtree::private_view<rtree> and detail::rtree::const_private_view<rtree> to access depth and apply_visitor
If you had any problems the Boost.Geometry mailing list is a good place to ask questions.

Boost C++ Libraries: Ticket #11247: More useful rtree API (public apply_visitor, ...)

type, summary changed; keywords set