Boost logo

Geometry :

Subject: Re: [geometry] Integrating OGR library with Boost.Geometry
From: Eric MSP Veith (eveith_at_[hidden])
Date: 2015-05-26 07:43:59

Hello Menelaos,

On Friday 22 May 2015 17:33:35, Menelaos Karavelas
<menelaos.karavelas_at_[hidden]> wrote:
> > My OGRPointCollectionIterator is both default and copy constructible:
> I think the question is whether your mutable iterator is convertible to
> your const iterator, or to pose it differently, whether your const
> iterator is constructible from your mutable iterator (which should be
> the case).

I'm still puzzled. I've checked my iterator code and updated some of it in
order to have it adhere to the Boost iterator_facade howto as closeley as
possible. Specifically, I made sure that `MyConstIterator iter =
boost::begin(someNonConstLineString);` works, which would cause the iterator
to be converted to the const iterator.

So I assume that it is not the iterator that is at fault.

Checking your example and investigating the Boost.Geometry headers, I see that
the bg::model::linestring<...> trait relies on several functions via
dispatching that are present in std::vector and other container types, but not
in OGRLineString. This includes, as seen from the compiler error I posted
previously, clear(), push_back(), and resize().

I'd now open up the boost::geometry::traits namespace and provide dispatch
structures for these operations along the lines of...

template <>
struct clear<OGRLineString>
    static inline void apply(
            typename rvalue_type<OGRLineString>::type range)

Would that be the correct approach or merely a hack?


Geometry list run by mateusz at