Thank you for the feedback. As it turns out, there was a bug in the selfintersection algorithm that I used. This lead to the "V"-polygon being identified as having selfintersections. I have replaced it with a newer, vectorbased one that seems to yield better results.
I have also added the (optional) "resolution"-parameter you requested.
The self-intersecting extended polygon (from the "banana"-poly) still occurs as I have not found out why this happens. When I do, I'll update again.
The algorithm wasn't intended for use with negative ranges. I originally made for plotting weapon ranges from areas a threat is expected which entails only positive ranges.
I've allowed the code to run with negative ranges, as I have observed some results that seemed correct, but it generates a warning as I have not really tested it and it wasn't originally intended to do so.
The NaN scenario has not occured to me (I do not have the mapping toolbox) but I can imagine that it would be possible to modify it in order to run the code on each segment. The code is intended for a single segment.
A work around for this should probably look like something along these lines:
[mcode]
P0 = [rand(3,2);NaN,NaN;rand(3,2)];
%rewrite the segmented polygon to a cell array
segmentCounter = 1;
pointIndexCounter = 1;
for i=1:size(P0,1)
if ~isnan(P0(i,1))
P0cell{segmentCounter}(pointIndexCounter,:)=P0(i,:);
pointIndexCounter = pointIndexCounter + 1;
else
segmentCounter = segmentCounter + 1;
pointIndexCounter = 1;
end
end
Thank you for your feedback John. Discovered and fixed a small bug in determining if the input polygon is defined CW or CCW.
Please note that your test code should read:
"P1 = extendPoly(rand(3,2) , .1 );" should read "P1 = extendPoly(P0 , .1 );" Because otherwise the extended polygon will always be different from the input.
I hope the self-intersecting extension issue can be fixed. Note that in the center of the V-poly extension there seem to be two identical points in the extended polygon (I just stepped through with a datatip + arrow keys).
Thank you for the feedback. As it turns out, there was a bug in the selfintersection algorithm that I used. This lead to the "V"-polygon being identified as having selfintersections. I have replaced it with a newer, vectorbased one that seems to yield better results.
I have also added the (optional) "resolution"-parameter you requested.
The self-intersecting extended polygon (from the "banana"-poly) still occurs as I have not found out why this happens. When I do, I'll update again.
Thanks for sharing this! The polygon extension is a most desirable function - but I think there is some unexpected behaviour with your code. I've tested some polygons with your help code
extendedPolygon = extendPoly(Polygon,0.4);
figure(1); clf; patch(Polygon(:,1),Polygon(:,2),'r');
for i=1:length(extendedPolygon)
toPlot=extendedPolygon{i};
line(toPlot(:,1),toPlot(:,2),'Color','b');
end
1) The v-like polygon
Polygon = [0,0;1,1;1,2;0,1.00;-1,2;-1,1;0,0];
produces an self-intersection error, while the very similar
Function does exactly what I expected, in my case expending freely drawn areas (polygons) by a given weapon range or sensor range.
Although it first glance the problem seemed simple, it is somewhat complex so thanks for posting this!!
The Nov 10 update fixes the bug I was seeing that generated empty results; the extended polygons created for my test polygons look good now. This function is still slower than bufferm.m (by about a factor of 10), but has the very nice advantage of not requiring the Mapping Toolbox. Thanks to the author for the quick response to comments.
I hope the self-intersecting extension issue can be fixed. Note that in the center of the V-poly extension there seem to be two identical points in the extended polygon (I just stepped through with a datatip + arrow keys).
But above all, thanks for your fast support!
5
28 Jan 2009
Accurate polygon extension
Enlarges polygon by a specified range. Also generates internal polygons caused by intersections.
Thank you for the feedback. As it turns out, there was a bug in the selfintersection algorithm that I used. This lead to the "V"-polygon being identified as having selfintersections. I have replaced it with a newer, vectorbased one that seems to yield better results.
I have also added the (optional) "resolution"-parameter you requested.
The self-intersecting extended polygon (from the "banana"-poly) still occurs as I have not found out why this happens. When I do, I'll update again.
Comment only
26 Jan 2009
Accurate polygon extension
Enlarges polygon by a specified range. Also generates internal polygons caused by intersections.
Thanks for sharing this! The polygon extension is a most desirable function - but I think there is some unexpected behaviour with your code. I've tested some polygons with your help code
extendedPolygon = extendPoly(Polygon,0.4);
figure(1); clf; patch(Polygon(:,1),Polygon(:,2),'r');
for i=1:length(extendedPolygon)
toPlot=extendedPolygon{i};
line(toPlot(:,1),toPlot(:,2),'Color','b');
end
1) The v-like polygon
Polygon = [0,0;1,1;1,2;0,1.00;-1,2;-1,1;0,0];
produces an self-intersection error, while the very similar
Polygon = [0,0;1,1;1,2;0,0.90;-1,2;-1,1;0,0];
does not.
2) Some banana-like (non-convex) polygons like
xt = (1:5).';
yt = log(xt);
Polygon = [[xt;flipud(xt) ;xt(1)],...
[ yt;flipud(yt)-1;yt(1)]];
produce a self-intersecting extended polygon, see the detail
xlim([4,4.2])
ylim([-0.02,0.02])
Plus: It would be nice to have control over the resolution of the circular sections of the extended polygon.
3
13 Jan 2009
Accurate polygon extension
Enlarges polygon by a specified range. Also generates internal polygons caused by intersections.
Function does exactly what I expected, in my case expending freely drawn areas (polygons) by a given weapon range or sensor range.
Although it first glance the problem seemed simple, it is somewhat complex so thanks for posting this!!
5
10 Nov 2008
Accurate polygon extension
Enlarges polygon by a specified range. Also generates internal polygons caused by intersections.
The Nov 10 update fixes the bug I was seeing that generated empty results; the extended polygons created for my test polygons look good now. This function is still slower than bufferm.m (by about a factor of 10), but has the very nice advantage of not requiring the Mapping Toolbox. Thanks to the author for the quick response to comments.
Comment only