Terence_13

Update: All good. Indeed Clipper2Lib works now for the "union of tiles" case described above. The glitches I saw where related to a minor bug in the tessellation library I use (fixed now). Combination of those glitches and the fact that Clipper2Lib does (not yet) merge touching polygons in the solution threw me off. Congrats: that is a major improvement to Clipper1! Bold red outline in the attached picture indicates the union solution polygon.

Update: All good. Indeed Clipper2Lib works now for the "union of tiles" case described above. The glitches I saw where related to a minor bug in the tessellation library I use (fixed now). Combination of those glitches and the fact that Clipper2Lib does (not yet) merge touching polygons in the solution threw me off. Congrats: that is a major improvement to Clipper1!

EDITED (red outline was not result union but rather later process step clipping against earth features) Hmm...you might be right that it is technically correct. GREAT work! Clipping against the earth polygon features is a bit glitchy (see bottom left corner in Clipper2Lib picture)...need to investigate this further. See attachment. This is really difficult to reproduce and provide you samples with as the individual tiles are randomly "unified". A difficult situation is e.g. when 8 tiles have been...

Hmm...you might be right that it is technically "sort of" correct (there are some weird "spike-lines" instead of rectangles). See attachment. This is really difficult to reproduce and provide you samples with as the individual tiles are randomly "unified". A difficult situation is e.g. when 8 tiles have been merged in 3x3 tiles, and the last tile fills a hole in the middle vs top right corner tile missing. If you see in the attached picture something unexpected, maybe you are able to synthesize a...

Hmm...you might be right that it is technically "sort of" correct (there are some weird "spike-lines" instead of rectangles). See attachment. This is really difficult to reproduce and provide you samples with as the individual tiles are randomly "unified". A difficult situation is e.g. when 8 tiles have been merged in 3x3 tiles, and the last tile fills a hole in the middle vs top right corner tile missing. If you see in the attached picture something unexpected, maybe you are able to synthesize a...

Hmm...you might be right that it is technically "sort of" correct (there are some weird "spike-lines" instead of rectangles). See attachment. This is really difficult to reproduce and provide you samples with as the individual tiles are randomly "unified". A difficult situation is e.g. when 8 tiles have been merged in 3x3 tiles, and the last tile fills a hole in the middle vs top right corner tile missing. If you see in the attached picture something unexpected, maybe you are able to synthesize a...

However, I'm not sure if the line if (cnt < 3) return 0.0; is needed. It looks safe to remove (though I'm yet to test this). Indeed, in my framework the area function looks like this: public static double AreaNew(PathD path) { double a = default; for (int i = 0, cnt = path.Count; i < cnt; j = i++) a += (path[j].y + path[i].y) * (path[j].x - path[i].x) * 0.5; return a; } While the double version does not need any type casting, the integer version does need it and looks like this: public static double...

However, I'm not sure if the line if (cnt < 3) return 0.0; is needed. It looks safe to remove (though I'm yet to test this). Indeed, in my framework the area function looks like this: public static double AreaNew(PathD path) { double a = default; for (int i = 0, cnt = path.Count; i < cnt; j = i++) a += (path[j].y + path[i].y) * (path[j].x - path[i].x) * 0.5; return a; } While the double version does not need any type casting, the integer version does need it and looks like this: public static double...