
Geometry : 
Subject: Re: [geometry] boost::geometry::touches(point, box) does not compile
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 20190108 18:01:10
Hi Brook,
Brook Milligan Via GeometryÂ wrote:
> I am curious why the following code does not compile.
>
> #include <boost/geometry/algorithms/touches.hpp>
> #include <boost/geometry/geometries/box.hpp>
> #include <boost/geometry/geometries/point_xy.hpp>
>
> int main ()
> {
> using point_type = boost::geometry::model::d2::point_xy<int>;
> using box_type = boost::geometry::model::box<point_type>;
>
> point_type point { 0,0 };
> box_type box { {0,0},{1,1} };
> boost::geometry::touches(point,box);
> }
>
> It seems that touches() is not implemented for a point and a box, although it would seem to be simple to implement.
It might be unintentional however I could think of a reason. The main
reason may be that Box is not defined by the OGC standard used in
Boost.Geometry. To be more precise:
It's not clear what is a valid box. Consider e.g. when Box degenerates
to a segment or point (e.g. box{{0,0},{0,0}}) typically this would be
considered valid because it might be a nonenlarged bounding box of a
point. On the other hand if we represented it as polygon it would be
invalid because it has area = 0. Now considering that relational
operations in Boost.Geometry are defiend by DE9IM model
(https://en.wikipedia.org/wiki/DE9IM), should we treat this degenerated
box as point (it'd have only the interior and no boundary) or as some
kind of degenerated areal geometry (only boundary but no interior) or
maybe some wierd hybrid (both interior and boundary at the same point)?
In either of these cases the result of touches(point, box) would be
different and in the last case ambiguous. So this function might have
been ommited because it wasn't clear what should be the result and to
just deal with it in the future if someone really needs it.
Another issue is that since bounding boxes are used for indexing and are
not OGCgeometries we may treat them differently than the other
geometries when the speed is important. E.g. relational operations for
boxes does not check equality of coordinates using machine epsilon. This
means that touches(point, box) and touches(point, polygon) could return
different result for cases like this:
Â Â Â touches(point{0eps/2, 0}, box{{0,0},{1,1}});
Â Â Â touches(point{0eps/2, 0}, polygon{{{0,0},{0,1},{1,1},{1,0},{0,0}}});
This is a lesser problem (sort of) because intersects() or covered_by()
probably already returns different results. The first case would
probably use strict coordinates comparison without epsilon and my guess
is that someone might think that it wouldn't be that useful. Boxes are
used as bounding objects of other geometries and I cannot think of a use
for finding out it a point touches a bounding box of some geometry.
Unless a box is not used as bounding object but then the way how the
coordinates are compared could depend on the specific use case.
Are you in need of this or asking out of curiosity?
What would you like to use it for?
Adam
Geometry list run by mateusz at loskot.net