Dan Baston

I think we're ok, the failure was fixed in `main` at 433b91aa0bba05ce8833f5831a4bd82e8450a9e8

It sounds like exposing `LengthIndexedLine::extractLine` in the C API would meet this need? https://github.com/libgeos/geos/blob/cc667261086d8e5f9906b69f4feaea5112221e92/include/geos/linearref/LengthIndexedLine.h#L96-L107

> As an initial "what-if" comment, since the LineIntersector is now just a container for a PrecisionModel, what if the PrecisionModel is the value passed around, and LineIntersector and IntersectionResult...

This is on top of cascaded union. This prevents the pieces that don't intersect from going into the overlay engine together.

The first and last columns ("geometry clusters" and "envelope clusters") give some idea of this. Canadian subdivisions (last row) form 175k geometry clusters but only 7k envelope clusters.

Maybe it's possible to do a reasonable algorithm selection based on average number of vertices/polygon. Above a certain number of vertices/polygon the union operation can be expected to be expensive...

> Very exciting. I think the preparedgeometryxy stuff is going to be required anyways Yes, even with the `FixedSizeCoordinateSequence` the cost of creating and destroying points is about the same...

I don't think the current implementation is the final implementation, but switching to a concrete class makes experimentation a bit easier, I think. Here is one way to handle multiple...

Backing `CoordinateSequence` with `double*` turns out to be pretty invasive, because we lose the ability to construct a `CoordinateSequence` without copies by moving in a `std::vector`. The code is full...

My comment probably wasn't clear. I am working on a `CoordinateSequence` variant that is backed by a buffer of doubles (thus allowing different dimensionality, but not relaxing the interleaving requirement)....