Tree based acceleration for polygon clipping / boolean ops

[asinghvi17]

Can use STRtrees (expensive to construct, efficient to query) or Natural trees (from tg, cheap to construct, ~same query speed for our usecases)

There are three methods here:

• naive, n*m nested loop
• loop over all edges of a, tree on b
• dual tree query on trees from a and b

This algorithm should be easily portable to s2 when that becomes available - and the structure allows e.g. manifold passthrough as well.

---

This PR also adds a LoopStateMachine module that basically just defines an Action wrapper struct, and a macro that can take care of that action wrapper struct.

With this macro, a function running within a loop can return Break() or Continue() which indicates to the caller that it should break or continue.

E.g.:

f(i) = i == 3 ? Break() : i
count = 1
for i in 1:5
    count = @processloopaction f(i)
end
count # 2

---

TODOs:

• add rejection tests for duplicate points
• add lopsided single tree query
• add dual tree query
• figure out good heuristics for when to choose which
• establish tree construction and query benchmarks on various cases
• port the tg benchmarks here
• add more tests and benchmarks with complex polygons

[asinghvi17]

• Tree based acceleration for polygon clipping / boolean ops #274 : 2 dependent PRs (#278 , #283 ) 👈 (View in Graphite)
• Algorithm + manifold and accelerator passthrough in clipping functions #273
• Spatial tree interface #297
• Convert the orient predicate to AdaptivePredicates + minor predicate changes #275
• Add a TGGeometry extension for fast inexact geometric predicates #271 : 1 other dependent PR (#291 )
• [Core] Add an algorithm interface + StableTasks #269 : 1 other dependent PR (#282 )
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[asinghvi17]

Looks like the SingleSTRtree implementation is ignoring some edges somehow...will have to give the a_list and b_list a look later on, maybe during the hackathon.

[asinghvi17]

Looks like the one largeish error here is in difference(p25, p26; target = GI.PolygonTrait()) specifically with SingleNaturalTree:

the colorful ones are the polygons generated from difference individually - the base poly is blue.

here's what it looks like with the base nested loop:

and here's what it looks like with geos:

This is also somehow spitting out invalid polygons according to libgeos, it doesn't tell me why though.

[asinghvi17]

It may be, that this is because the algorithm is returning degenerate (self intersecting) polygons.

LG.isValidReason on the first result polygon gives me a self intersection, you can see it here:

the reason is specifically "Ring Self-intersection[4.5 1]"

[asinghvi17]

ah this is pretty bad actually, polys 1 and 4 both have self intersections...and the hole detection is not working. This is all the outputs, colored by index in the output array:

and this is what it should look like:

[asinghvi17]

somehow single natural tree seems to be swapping the order of intersects....

[asinghvi17]

Argh, I forgot to add a hook for f_after_each_a in the loop.....need to switch this to SpatialTreeInterface proper asap!

Here's what I am thinking - intersection accelerators can get simpler.

struct NestedLoop end
struct TreeAccelerated{Tree1, Tree2}
    treetype1::Tree1
    treetype2::Tree2
end

the trees in there can be tree specs that then get instantiated, I'm thinking something like your ArgsAndKwargs @rafaqz