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.