
Geometry : 
Subject: Re: [geometry] Incorrect results from bg::equals (problem with closure and collect_vectors?)
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 20170409 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 equalcompared by equalcomparison 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 speedup the rtree::remove().
FYI, Boxes shouldn't be treated as Polygons. In cartesian coordinate
system they indeed correspond to each other. But in noncartesian
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.
Geometry list run by mateusz at loskot.net