So Mathematica uses an even-odd rule for self-intersecting polygons, both when rendering them and when calculating their area:
poly = Polygon@{{0., 0}, {3, 0}, {3, 2}, {1, 2}, {1, 1}, {2, 1}, {2, 3}, {0, 3}};
Graphics@poly
(* See image below *)
Area@poly
(* 7. *)
RegionMeasure@poly
(* 7. *)
But the area calculation doesn't seem to work when one of the vertices is repeated:
poly = Polygon@{{0., 0}, {3, 0}, {3, 3}, {1, 3}, {1, 1}, {3, 1}, {3, 3}, {0, 3}}
Graphics@poly
(* See image below *)
Area@poly
(* 13. *)
RegionMeasure@poly
(* 13. *)
I'd expect the area to be 5
as can be shown by slightly offsetting the points in the corner:
poly = Polygon@{{0., 0}, {3, 0}, {3, 2.999}, {1, 2.999}, {1, 1}, {2.999, 1}, {2.999, 3}, {0, 3}}
Area@poly
(* 5.004 *)
RegionMeasure@poly
(* 5.004 *)
It seems that the areas of the convex parts of the polygon are actually added instead of subtracted if I've got repeated vertices.
This looks likes a bug to me, but is it? Is there a fix other than applying random offsets on the order of the machine epsilon to the vertices?
Note that I am not interested in fixing the above example to a simpler non-intersecting polygon unless this can be done programmatically in the general case. I've only chosen such a simple example to illustrate the point. Assume that the polygon could be arbitrarily complex with repeated vertices.
Polygon@{{0, 0}, {3, 0}, {3, 3}, {1, 3}, {1, 1}, {3, 1}, {3, 3}, {0, 3}}
, the computed area is4
instead of5
. $\endgroup$4
is even weirder than5
. If I callDiscretizeGraphics
first I still get13
by the way. As for your rephrasing, yes, that's fairly accurate, although I'd like to stress that I'm not looking for general polygon area algorithms, but rather for a way to makeArea
orRegionMeasure
work for general polygons (or a good reason why they don't work in the presence of repeated vertices). But it looks like your answer provides that (at least the former). :) $\endgroup$