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, 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
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.
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
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.
Geometry list run by mateusz at loskot.net