Geometry Boost List: Re: [geometry] boost::geometry::touches(point, box) does not compile

Subject: Re: [geometry] boost::geometry::touches(point, box) does not compile
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 2019-01-08 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 non-enlarged 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/DE-9IM), 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 OGC-geometries 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{0-eps/2, 0}, box{{0,0},{1,1}});
 Â Â Â  touches(point{0-eps/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