Geometry Boost List: [ggl] spacial index construction interface

Subject: [ggl] spacial index construction interface
From: Bruno Lalande (bruno.lalande)
Date: 2011-03-07 07:13:42

Hi,

>
>> So std::vector< std::pair<Box, node_pointer > > was in leafs but not used.
>> Now this is implemented as follows:
>>
>> [...] I've also changed some names to better describe variables.
>>
>
> Great. If a vector is not used, it should go indeed. Perfect.
>

Hmm I'm not sure... This reminds me the way in which script languages like
Python or Perl implement "pure" virtual functions by just having their
default implementation throw an error, while compiled languages allow the
function not to exist at all when not needed (and thus "throw" at compile
time).

This function should not even be virtual. Leaf and Node should have there
own set of (non virtual) specific functions only applicable to them, and
those functions should be called by double dispatch. With double dispatch,
once you are in the second step of the dispatching process, you know (at
compile time) that you are manipulating a node or a leaf, and you can call
methods on them which are not virtual at all, and don't exist in the base
class.

And if no such specific method exist (i.e. if there's nothing you can do
with a leaf that you can't do with a node and the other way around) then
there should only be one class, with a container of itself, and testing for
leaf boils down to testing that container for emptiness. But I guess you're
not in this case?

>
> One of the things I've remarked in the past (> year ago) is: can we avoid
> virtual functions here? The spatial index as implemented was reported as
> slower than usual, or possible, don't know the details. If you're now diving
> into this, can you see if there are improvements possible?
>

Yep, that's basically the intention in my point above: avoid as much virtual
stuff as possible.

> 1. Bruno mentioned that he has an idea for a slightly different translator.
>>
>
Well I've thought a bit about that and I don't think I can come up with
anything much better. If I summarize, the translator is basically just a
function (which takes an index and returns the corresponding indexable) so
maybe we should call it Translate or GetIndexable or something like that to
state that more clearly. And more important, we should ensure a
boost::function or any Boost or STL binder can be used. Does that make
sense? Basically, I'd like to somehow state more clearly that this is just a
function/functor.

 geometry::index::remove(spatial_index, value);
>> geometry::index::remove(spatial_index, value_first, value_last);
>> geometry::index::remove_from(spatial_index, box);
>>
>
> Yes, this is symmetric to insert. I don't know if a box is often used for
> removal, intuitively I would remove everything outside a box, to concentrate
> on that area.
>

By removing from a box, do you mean removing all the data which is in the
box represented by one of the nodes/leaves of the tree? Or removing all data
which is geometrically contained by an arbitrary box? In the first case, I
don't think it makes sense (the user is not even supposed to be aware of the
internally structure, so not supposed to be interested in basing some
removal upon an element of the structure). In the second case, it might make
sense to have such function.

Regards
Bruno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/ggl/attachments/20110307/36b8652e/attachment.html