On 24 April 2018 at 05:55, Adam Wulkiewicz via Geometry <geometry@lists.boost.org> 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