Geometry :

vschoech_at_[hidden]

--
Volker Schöch | vschoech_at_[hidden]<mailto:vschoech_at_[hidden]>
Senior Software Engineer
We are looking for C++ Developers: http://www.think-cell.com/career
________________________________
think-cell Software GmbH        http://www.think-cell.com>
Chausseestr. 8/E        phone / fax     +49 30 666473-10 / -19
10115 Berlin, Germany   US phone / fax  +1 800 891 8091 / +1 212 504 3039
Amtsgericht Berlin-Charlottenburg, HRB 85229 | European Union VAT Id DE813474306
Directors: Dr. Markus Hannebauer, Dr. Arno Schödl
From: Geometry [mailto:geometry-bounces_at_[hidden]] On Behalf Of Barend Gehrels
Sent: Montag, 24. November 2014 19:53
To: Boost.Geometry library mailing list
Subject: Re: [geometry] Equivalence between (multi-)polygons with spikes (3)
Hi Volker,
I had to digest your replies a little ;-) Hopefully I can give some more answers now and later.
Volker Schöch wrote On 20-11-2014 13:06:
bg> E.g. your sample (in the ticket) with two points, where a spike is removed, results in a polygon with only one point. That is IMO a perfect result from remove_spikes. Because the spike is removed. remove_spikes should do nothing more than that... Why should it remove a remaining point - that point is not a spike. And remove_spikes should not change anything but spikes...
bg>
bg> That the result is still not as desired, OK, I understand that but... that should be implemented in another function (e.g. correct).
Thank you for the explanation. I'm not yet convinced. What exactly is the definition of a "spike"? How is a single point not a spike? It's a boundary that doesn't contain/represent any points of the polygon.
No, a single point is not a spike. It is not a valid polygon, but a spike goes forwards and backwards over the same path, so a segment but it can also make a corner (or more corners).
If you consider a diamond-shape with a spike at one of its corners, the spike is removed but exactly the point where the spike leaves the rectangle is kept, of course. So the point at the base of the spike is kept. That is why that single point is kept...
It might be debatable whether a single point is a spike and should be removed by remove_spikes(). However, it seems crystal clear to me that when removing spikes, the result cannot be a single point.
For me it is not that clear. I had to think about it but I think the current implementation is right. What if you have a polygon with two holes. One of two holes is spike-only, so a single point remains. Of course it is not valid, but should remove_spike remove that single point? That results in a hole with zero points (empty). Should it then remove that empty hole from the interior-ring container ? I really think that is outside its responsibility.
Same story for multi-polygons, suppose 5 of the 10 polygons of a multi-polygon are spike-only. Resulting in 5 single-point geometries. Should they be removed from the multi-polygon resulting in 5 ?
Again: What exactly is a spike? Which points constitute a spike? In the example there was a polygon representation that consists of only a spike, i.e., the polygon does not have any points. It consists of a spike! Removing the spike is removing the polygon representation, seems obvious to me. The representation does not enclose any points, it is a spike, it should be removed. What's so special about one point or the other, that some points are removed from the representation but one remains?
Well, yes, these are good questions and we might consider removing the only point from the spike, leaving an empty polygon or interior rings with partly empty rings or multipolygons with partly empty polygons after that.
Taking into account the whole remove_spikes operation exists and is released is partly your responsibility ;-) you also have some influence and I'm curious what you find now.
So after calling remove_spikes the user should call correct, which should remove rings which are empty from interior rings and polygons which are empty from multi-polygons (it currently does not do that, but from "correct" you might expect that).
Regards, Barend