Subject: Re: [geometry] ring, multi_polygon concepts too limited or not
From: Barend Gehrels (barend_at_[hidden])
Date: 2013-09-02 19:40:53
On 2-9-2013 23:05, lepere renaud wrote:
> I have implemented geometric concepts above a legacy geometry
> structures where ring and multi_polygon are not an stl container but i
> have compiling problems on some functions while using the library.
> It leads to a error in backtrack_check_si.hpp
> template <typename Geometry1, typename Geometry2 >
> class backtrack_check_self_intersections
> // Make bad output clean
> ring.clear(); <- here this method does not exist
> 2. read_wkt
> MultiPolygon mp;
> boost::geometry::read_wkt(s, mp);
> line52 of multi/io/wkt/read.hpp l52 contains "geometry.back()" while
> i don't have a container. a few lines above there is a line with
> traits::resize<MultiGeometry>::apply(geometry, ...) which suggests
> that here geometry should not necessarly be an stl container.
Sorry for these calls of, indeed, non-concept method. They should be
fixed. .back() is easy to avoid.
> As suggest by Bruno, it looks like the library is using this
> ring/multi_polygon as a container while the Ring/MultiPolygon concept
> specifies that Range requirements are supposed to suffice.
Range is enough for const Rings. But here (and also in wkt) polygons
must be written. As was also recently on the list. There are no standard
concepts we can use (such as in Boost.Range), so we made a minimum
traits class ourselves. But apparently it is not yet called everywhere,
indeed we have no unit-tests yet for classes as yours. The traits also
have to be extended by something to erase a point from a Range
It will be fixed.
Thanks for the report.
Geometry list run by mateusz at loskot.net