Geometry Boost List: Re: [geometry] Adaption of legcay hierarchy to Boost.Geometry model

Subject: Re: [geometry] Adaption of legcay hierarchy to Boost.Geometry model
From: ïÌÅÇ íÉÈÁÌ£× (mihis.sakh_at_[hidden])
Date: 2013-02-05 07:39:37

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:
http://boost-geometry.203548.n3.nabble.com/Using-Boost-Geometry-with-a-legacy-class-hierarchy-td3734832.html
.
It resulted in suggestion by Barend of such code -
http://boost-geometry.203548.n3.nabble.com/attachment/4025044/0/newapproach.zip.

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?

Regards,
Mihis

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?
>
> Regards
> Bruno
>
>
> _______________________________________________
> Geometry mailing list
> Geometry_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/geometry
>
>