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
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
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
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
Yes, it's a check to quickly reject polygons before analysing
P.S. I have permission to release the fix with Boost 1.64.