Subject: Re: [geometry] Adaption of legcay hierarchy to Boost.Geometry model
From: ïÌÅÇ íÉÈÁÌ£× (mihis.sakh_at_[hidden])
Date: 2013-02-08 02:57:24
OK, it seems that I have found answer for this question.
*. it's mentioned that besides
specialization of traits::tag and and lifting of Boost.Range Random Access
concepts custom linestring class
also must "implement std::back_insert_iterator either by implementing
push_back or by specializing
std::back_insert_iterator". The same if for the Ring Concept. I really
can't understand how to "specialize
std::back_insert_iterator" but it seems to me that this phrase means the
necessity of specialization of
structs *resize*, *push_back* and *clear* from *mutable_range.hpp*, which
are used by *append* and *assign* algorithms.
I have not tested this solution yet but it seems to be right taking in
account that Boost.Polygon data structures
are adapted to Ring and Polygon Concepts in the same way.
2013/2/5 ïÌÅÇ íÉÈÁÌ£× <mihis.sakh_at_[hidden]>
> Hi, Bruno.
> Thank you for your reply. Now I understand the problem with the design of
> my class hierarchy.
> However there is still one thing, that I don't understand at all. Some
> time ago there was a discussion about the adaption of legacy class
> hierarchy to Boost.Geometry model:
> It resulted in suggestion by Barend of such code -
> As I understand this is an example of complete adaption of custom Point,
> Linestring and Ring classes to Boost.Geometry model.
> But assume that objects of my simple Linestring class include private
> container for Points. Int the code, presented by Barend I can't see
> anything that should
> provide possibility for certain algorithms of Boost.Geometry to change
> inner Point data of Linestring objects (add or remove Points for example).
> Or some methods like push_back, insert and etc. must be also defined in my
> Linestring (Ring, Polygon) classes?
> I couldn't find any information, covering this issue, in Boost.Geometry
> official docs. Can you help with this problem?
> 2013/2/2 Bruno Lalande <bruno.lalande_at_[hidden]>
>> Hi Mihis,
>> The problem is, you are trying to adapt a structure which is
>> fundamentally read-only. I mean the calculated curve itself is read only,
>> and that's what you're trying to adapt to the linestring concept, as
>> opposed to adapting the inner segment used for the curve calculation.
>> So as you have guessed, only the non-mutating algorithms will be
>> available to you (things like distance, length, etc). It wouldn't make any
>> sense, by definition, to try to mutate your curve since it's a calculated
>> thing so modifying any of its points would potentially break the validity
>> of the curve in regards to the algorithm that generated it.
>> However, I still understand the value of using algorithms like buffer and
>> simplify on your calculated curve. You'll simply have to use a different,
>> mutable, non-calculated structure as the output. Could be the
>> Boost.Geometry linestring class or anything else. Anything that fulfills
>> the linestring concept and is not a read-only calculated thing. And you can
>> then use it for whatever further processing you need to do with the
>> simplified/bufferized/mutated curve. Of course this will never be fed back
>> to the original curve class since, as we said, it's a calculated and
>> immutable thing.
>> Does that make sense at all?
>> Geometry mailing list
Geometry list run by mateusz at loskot.net