Geometry Boost List: [ggl] spacial index construction interface

Subject: [ggl] spacial index construction interface
From: Adam Wulkiewicz (adam.wulkiewicz)
Date: 2011-03-07 12:17:08

Barend Gehrels wrote:
> Great. If a vector is not used, it should go indeed. Perfect.
>
> 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?
>
> In the currently running xint review the CRTP is proposed instead of
> virtual functions, and it might be that this is also possible here. If
> so, that is probably preferable.

Details in this case could be usefull.

There are many things which might be changed. Nevertheles, we need 
runtime polimorphism so there must be virtual functions or some 
condition check with type casting. All in runtime. CRTP is compile-time 
technique.

More in the next email.

>> geometry::index::insert(spatial_index, value);
>> geometry::index::insert(spatial_index, value_first, value_last);
>
> I think this is a very good idea and similar to how Boost.Geometry is. I
> didn't think earlier to apply this for spatial indexes, but I think it
> is a good idea.
>
> What is exactly value_first, value_last? Do you mean iterators here?

Yes, but this is only an example since the interface should be as simple 
as possible.

>> If functions won't be implemented for some container, default ones
>> will be used. Lack of needed methods will cause compilation error.
>>
>> 4. There is functionality of removing elements from spatial index.
>> User may want to remove exact value or all values inside some box. If
>> value is a box, we have two methods remove(...) with the same
>> parameter. Simplest way to avoid it is to change the name of one
>> method. I've implemented remove(Value) and remove_in(Box) but maby you
>> have better idea? I now realised that better name would be
>> remove_from(Box).
>>
>> Then:
>>
>> 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.
>
> Is index::remove_if(spatial_index, condition_functor);
>
> an idea? You can build a functor then and specify a box, and if removal
> should be inside or outside.

I've just presented what is implemented in the rtree. There are two 
remove() methods. First takes Value and second takes Box but in the 
second case only an element with box equal to the parameter is removed 
(btw, function description is wrong).

Regards,
Adam