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 13:59:10

Hi Chris,

Ch'gans wrote:
>
> 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.

Boost.Geometry requires that the coordinates of the min corner of a box 
has to be lesser or equal to the coordinates of max corner. This is true 
for all coordinate systems. E.g. in geographic a Box overlapping the 
antimeridian could contain the points: min_corner: (179, 0), max_corner: 
(181, 1), even though for other geometries these coordinates would be 
outside the range of validity.
See also: http://www.opengeospatial.org/standards/sfa page 16 Envelope

So if you're creating Boxes by yourself (not with bg::envelope() 
function) then I'd suggest to always make sure they're normalized.

> 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?

Boxes are equal-compared by equal-comparison of min and max coordinates.
https://github.com/boostorg/geometry/blob/develop/include/boost/geometry/algorithms/equals.hpp#L92
Relational operations for Boxes has to be as quick as possible. Boxes 
having max < min are considered to be invalid so I think this case 
shouldn't be handled. Unless you have a good reason for this?

If anything I'd consider to replace math::equals with more strict but 
faster operator== comparison, both to speed it up and to make it 
consistent with other relational operations for Boxes which checks 
coordinates with operators like <= or <, so without math::equals. This 
could potentially speed-up the rtree::remove().

FYI, Boxes shouldn't be treated as Polygons. In cartesian coordinate 
system they indeed correspond to each other. But in non-cartesian 
coordinate systems they're different, e.g. in spherical CS horizontal 
segments of a Box are fragments of parallels but segments of a polygon 
are fragments of great circles. BG currently allows to perform various 
operations for Box/Polygon and treats Boxes as Polygons, but that's 
incorrect IMO.

> I would like to highlight that bg::area() on such a box, returns the
> correct area (positive).

Yes, that's possible. Some operations may return valid output even for 
invalid input but that an exception, not a rule.

> 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
> box.

Yes, it's a check to quickly reject polygons before analysing segments.
https://github.com/boostorg/geometry/blob/develop/include/boost/geometry/algorithms/equals.hpp#L199
https://github.com/boostorg/geometry/blob/develop/include/boost/geometry/algorithms/equals.hpp#L139

Adam

P.S. I have permission to release the fix with Boost 1.64.