Subject: Re: [geometry] Integrating OGR library with Boost.Geometry
From: Menelaos Karavelas (menelaos.karavelas_at_[hidden])
Date: 2015-05-26 07:47:20
On 26/05/2015 02:43 Î¼Î¼, Eric MSP Veith wrote:
> 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?
Yes, this IS the correct way. You need to specialize various
metafunctions in bg::traits namespace so that things work.
Please keep us posted about this.
> Geometry mailing list
Geometry list run by mateusz at loskot.net