Boost logo

Geometry :

Subject: Re: [geometry] Incorrect results from bg::equals (problem with closure and collect_vectors?)
From: Ch'Gans (chgans_at_[hidden])
Date: 2017-04-09 11:52:50

> On 9 April 2017 at 22:05, Adam Wulkiewicz <adam.wulkiewicz_at_[hidden]> wrote:
>> Ch'gans wrote:


>> But unfortunately i still have some left: Comparison for geometry
>> equivalence of a box and a ring.
>> The problem is again in collect_vectors, the specialisation for bbox
>> always collect the points by following the clockwise direction, if
>> your have counterclockwise rings then equals(ring, box) will always
>> return false due to different directions.
>> Not sure what is the best way to fix this, any thoughts?
> 2 solutions come to mind:
> 1. Always gather segments/vectors in the same order, like this (pushed to
> develop):
> 2. In the constructor of collected_vector use lexicographically smaller
> point as the origin point, so always store point-order-invariant direction.
> It'd require to modify these constructors:
> I've choosen the first solution because it's simpler. I also expect it to be
> faster but haven't done performance tests.

Hi Adam,

Thanks again for the quick fix! Another couple of expected failures gone! ;)
Thanks as well for sharing your other ideas on how this can be done,
it's always good to discover new things and get familiar with the
inners of BG.

I have a last bg::equals test marked as expected failure, but i'm not
sure about that one:
If you construct a box with their two corners swapped, eg:
Box(Point(2, 2), Point(1, 1)), then bg::equals with the normalised
version of the box returns false. That is:
bg::equals(Box(Point(2, 2), Point(1, 1)), Box(Point(1, 1), Point(2,
2))) = false;

Conceptually, they are geometrically equals, as boxes don't have a
concept of orientation like ring do.

My Box class doesn't automatically correct for this since the user
might want to create such a box for whatever reason.

Do you think that this is a bug, or is it expected or officially
undefined, as the box is degenerated?
I would like to highlight that bg::area() on such a box, returns the
correct area (positive).
I vaguely remember seeing code in BG that check for equality using
area (may well be ring/polygons), obviously it's not the case for the


> Adam

Geometry list run by mateusz at