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

Subject: Re: [geometry] Adapting a model
From: Barend Gehrels (barend_at_[hidden])
Date: 2014-03-26 05:10:33

Hi,

TONGARI J wrote On 26-3-2014 4:09:
> 2014-03-26 5:29 GMT+08:00 Barend Gehrels <barend_at_[hidden] 
> <mailto:barend_at_[hidden]>>:
>
>     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.
>
>
> Doesn't geometry::make require the geometry default constructible?
> AFAIK, there's no such trait for point construction.

Yes, sorry I misread it. Mutable points should be constructible by 
default, indeed. There is no trait for this.

Regards, Barend