Geometry Boost List: Re: [geometry] Incorrect results from bg::equals (problem with closure and collect_vectors?)

Subject: Re: [geometry] Incorrect results from bg::equals (problem with closure and collect_vectors?)
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 2017-04-09 00:05:15

Hi,

Ch'gans Via Geometry wrote:
> Hi there,
>
> My custom ring type is defined with an 'open' closure.
>
> When i try to compare 2 geometrically equivalent ring and box,
> bg::equals return false.
> While investigating using the debugger, i discovered that the call to
> geometry::collect_vectors() returns 4 points for a box, but only 3
> points for a ring, so my 2 geometries can never be equal.
>
> In my case, collect_vectors is dispatched to range_collect_vectors,
> and by the look of it range_collect_vectors doesn't care about the
> geometry object (and it's closure), since it sees only point
> (iterator) range.
>
> I found a similar thread back from 2014, but it actually deals with a
> different problem, see
> http://boost-geometry.203548.n3.nabble.com/Possible-bug-in-boost-geometry-equals-td4025819.html.

Right, it was something different:
https://github.com/boostorg/geometry/commit/7e3d0571f93b768f091da238f86e123e138d0c19

> And there is this bug report that seems to be equivalent to my use-case:
> https://svn.boost.org/trac/boost/ticket/11899

Thanks for the heads up. The component of this bug is set wrongly to 
'polygon' so we missed it.

> Am i missing something in my custom geometry trait adaptation? is it a
> bug in BG, or a known limitation?

It is a bug. I pushed a fix to develop:
https://github.com/boostorg/geometry/commit/657a5c80902edc9640a06571c2762a5dee591067
I'll try to release it with Boost 1.64.

> Could someone shed some light on this? Any point-out to example,
> documentation or archives would be welcome too.
>
> If this is the same bug as #11899, could the fix be as simple as
> making range_collect_vectors aware of the closure of the ring, or
> maybe simply add a specialisation for rings?

Yes it probably is. You could check the bugfix mentioned above.
As a workaround probably relate() could be used but there probably would 
be some difference in performance.

Regards,
Adam