Geometry Boost List: Re: [geometry] relate(box, areal/linear) not supported yet?

Subject: Re: [geometry] relate(box, areal/linear) not supported yet?
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 2014-09-01 09:53:59

Hi,

Feverzsj wrote:
> hi, list
> seems relate(box, areal/linear) is not supported yet in 1.56. Is there
> somthing special with this case? Can I just convert the box to a ring and
> use it with the general algorithm?
>

Do you have in mind the one in namespace detail?
To be clear, this is not officially released and the interface may be 
changed or it may be moved to namespace geometry (as everything in the 
detail namespace).

Boxes are not yet supported because:
- it's not clear to me how they should be handled if they were 
degenerated to Point or Segment (Boxes are not defined in the OGC standard).
- often it's possible to implement more efficient algorithm handling 
Boxes than more general cases like e.g. Rings and we wanted to handle 
the standard geometries first. Rings also aren't OGC geometries but the 
algorithm is the same as for Polygons.

Yes, you may convert Box to Ring, as long as a valid Ring is produced, 
i.e. it has a non-empty interior, non-0 area. In other words if for both 
Dimensions (denoted as I):

bg::math::equals(bg::get<0, I>(box), bg::get<1, I>(box)) == false

Otherwise a box degenerates to a Segment or Point and you could consider 
converting it into one of those Geometries instead of a Ring. It's 
because many algorithms doesn't support invalid geometries. In 
particular, I think detail::relate() shouldn't work for them. And it's 
impossible to represent degenerated Boxes as valid Polygons/Rings.

Just have in mind that representing Boxes as Segments or Points changes 
the definition of their boundaries and interiors. relate() or some 
relational boolean operations may return some unintuitive results, e.g. 
(in pseudocode):

touches(box(0 0, 2 1), linestring(0 2, 1 1, 2 2)) == true

but if the box degenerated to a Segment was treated as Linear geometry 
(e.g. Segment or Linestring) then

// if
touches(box(0 1, 2 1), linestring(0 2, 1 1, 2 2))
// was an equivalent of
touches(linestring(0 1, 2 1), linestring(0 2, 1 1, 2 2)) == false

because for touches==true, the interiors can't overlap and in this case 
they do, in point (1 1). I suppose this isn't a problem, I just wanted 
to point it out.

In cartesian CS the conversion should be ok. In other coordinate systems 
it may be more complicated. E.g. in spherical system the edges of such 
bounding box converted to a Ring would be defined by great circles 
(http://en.wikipedia.org/wiki/Great_circle) which may not always be 
desireable. The library is a little bit inconsistent here and I think we 
should work on that in the near future.

Regards,
Adam