Geometry Boost List: Re: [geometry] Adapting a model

Subject: Re: [geometry] Adapting a model
From: Barend Gehrels (barend_at_[hidden])
Date: 2014-03-25 17:29:42

Hi,

Adam Wulkiewicz wrote On 25-3-2014 3:42:
> Hi,
>
> Please don't answer on some email from a different thread if you want 
> to create another thread.
>
> -- Original message --
>
> Hello,
>
> I 'm looking to adapt a model for use with Boost.Geometry. To start off,
> I looked to get the intersects algorithm working with two linestrings -
> that fails due to six MPL assertions (unimplemented operation).(note
> that my model's linestring cannot be mutable - it should still be
> possible to use non-mutating algorithms on it?)
>
> To try to track what's going on, I opted to get it working with the
> example model adaptation instead; that fails to compile too, on line 934
> of get_turn_info.hpp:
>
> typename strategy::return_type result = strategy::apply(p1, q1);
>
> And I am afraid I cannot tell what is missing.
>
> (In short, I copied the example QPoint and QLineString adaptation and
> added a main() calling intersects() - this is what I tried to compile:
>
> https://gist.github.com/Kojirion/9624531
>
> Just one minor correction - changed QPoint::double to double because I
> assume that's the intention)
>
> Any clues would be appreciated,
>
> Albert
>
> -- End --
>
> According to this:
> http://www.boost.org/doc/libs/1_55_0/libs/geometry/doc/html/geometry/reference/concepts/concept_linestring.html 
>
> the Linestring should behave like a range of Points.
>
> I don't know what was the intention that led to the example model 
> adaptation but if you replace pointers to QPoint in your example with 
> just a QPoint it compiles, almost.
> Almost, because apparently the Point's default ctor is required by 
> Box's default ctor.
>
> Barend is default ctor a part of the Point Concept? Or should we think 
> about some other way of default creation of Boxes/Segments/etc.? 

No, a point does not need to have a default constructor. It is not part 
of the concept. There is already a sort-of-constructing function in the 
library and that is boost::geometry::make, returning a point with 
specified coordinates.

For Box/Segments we don't have this yet, so yes, we should think about that.

However, QPoint has a default constructor, so in code of library users 
it is fine if that constructor is used. As long as it does not leak into 
our library.

Regards, Barend