Subject: Re: [geometry] Using Boost.Geometry with a legacy class hierarchy
From: Mats Taraldsvik (mats.taraldsvik_at_[hidden])
Date: 2012-02-17 06:10:29
Hi,
With the help of boost::iterator_facade and stackoverflow.com [1], I've
almost managed to adapt the Ring concept to my legacy objects, but I got
a compile time error which I don't understand. As you can see from the
code, the iterator exposes QPoint* objects directly, so that should work
properly.
The cpp files and the errors from the build log is here [2].
[1]
http://stackoverflow.com/questions/9251537/how-to-create-a-boost-range-that-hides-multiple-layers-of-vectors-and-exposes-it
[2] https://gist.github.com/1852693
Regards,
Mats Taraldsvik
On 02/12/2012 05:11 PM, Barend Gehrels wrote:
> Hi Mats,
>
>
>>>> I think I've managed to adapt QPoint and QLineString, because the
>>>> result of the program is a correct WKT. However, if there are
>>>> better ways of defining a boost range for this purpose, I would
>>>> love to hear about it. (None of my functions are named
>>>> "range_value", and since the documentation states "The type defined
>>>> by the metafunction |range_value<...>::type| must fulfill the Point
>>>> Concept
>>>> <http://www.boost.org/doc/libs/1_48_0/libs/geometry/doc/html/geometry/reference/concepts/concept_point.html>",
>>>> I guess there is a better way...?)
>>>
>>> OK I see. Notice also
>>> ...\libs\geometry\example\with_external_libs\x06_qt_world_mapper.cpp and
>>> x01_qt_example.cpp in the same folder, but maybe you did already.
>>>
>>> As far as I can see this is correct. I did not compile it but you
>>> have done.
>>>
>>> The range_value meta-function is (AFAIK) automatically provided, as
>>> long as you adapt it properly to the range concept, and so to see
>>> you did. Maybe we should include that in the docs.
>>>
>>
>> I see. :) Perhaps provide a link in the Boost.Geometry docs to e.g.
>> the example I used in the Boost.Range docs as well?
>
> A link to the page in Boost.Range is added.
>
> Note that the range_value statement is correct in the docs. It states
> that the type defined by range_value should fulfill the point concept.
> It does not state that range_value has to be provided.
>
> I can add your sample but as it is it is already in an example, in
> another way. That might be confusing. So for the moment (deadline
> happens to be tomorrow) I'll wait with that. Thanks.
>
>
>>
>>>
>>>>
>>>> The next step is to adapt the QRing class. I need to create a
>>>> single iterator sequence that loops all of the linestrings
>>>> contained in the QRing::lines directly, but -- especially since I'm
>>>> not sure if the boost.range part of QLineString is done correctly
>>>> -- I don't know the right way to do it. Could you give me any pointers?
>>>
>>> So the linestring is done correctly, and the ring gets, in general,
>>> an equal implementation because they are similar w.r.t. ranges etc.
>>>
>>> What I don't understand is looping over linestrings contain in
>>> QRing::lines. But maybe I don't understand QRing::lines well.
>>> Basically Boost.Geometry's ring is a vector of points, which happen
>>> to form a closed polygon (without holes). So it is similar to a
>>> linestring.
>>
>> You are correct -- my legacy class hierarchy is laid out to maintain
>> the topology/shared geometry, which does not fit seamlessly into the
>> Boost.Geometry model. (You might recall discussion on this list a
>> while back.) Therefore, I will need to create an iterator that loops
>> over every linestring (and the linestring's points) in QRing::lines,
>> that masks as a single collection of points. Do you know how (and if)
>> I could achieve that somehow?
>
> Ah, now I remember, sorry. Yest that must be possible, but I've never
> tried this. So I currently cannot give you links how to do this. The
> challenge is to make an iterator properly walking over the various
> ring-pieces.
>
> Regards, Barend
>
>
> _______________________________________________
> Geometry mailing list
> Geometry_at_[hidden]
> http://listarchives.boost.org/mailman/listinfo.cgi/geometry