Geometry Boost List: Re: [geometry] R-tree segment query optimization

Subject: Re: [geometry] R-tree segment query optimization
From: Jeremy Murphy (jeremy.william.murphy_at_[hidden])
Date: 2018-04-24 00:03:51

On 24 April 2018 at 05:55, Adam Wulkiewicz via Geometry <
geometry_at_[hidden]> wrote:

> Jeremy Murphy Via Geometry wrote:
>
>
> I ended up implementing a hemisphere geometry, because I realized that I
> only need to search in that finite area.
>
> Not that it's particularly important, but I really meant a semicircle, as
I'm just working in 2D for now.

> If that's the case then this means that your overloads of bg::intersects()
> are not used by the compiler.
>
> Adding new kinds of geometries and implementing algorithms for them is
> more complex than writing an overload. If you want to go this way I could
> guide you but in general this shouldn't be needed.
>
> With some compilers the order of includes WRT the overloads may be the
> problem. E.g. try to implement the overloads before the library is included
> or instead of writing a function template (with typename Box) write a
> function taking a specific box type. The R-tree uses
> bg::model::box<bg::model::point<CoordinateType, Dimension,
> CoordinateSystem>> where the three template attributes of bg::model::point
> are taken from the Indexable. Or you could take this type from the R-tree
> (it's rtree::bounds_type).
>

OK, I'll try changing the order of header inclusion. Is that a compiler
defect that order of inclusion can make a difference? I'm currently using
GCC 6.4.0, but I have GCC 7.3.0 and Clang 6.0.0 installed too.

This shouldn't be needed if your overload of intersects() was used. This is
> only needed if you want to add a new kind (Concept) of Geometry.
>

If I end up doing a lot more with this semicircle shape then I guess a
concept might be worth adding, but I'll see how I go with the overloads for
now.

Thanks, cheers.

Jeremy