Dan Baston

I've put together additional implementations of `CoordinateSequence` that are: - backed by `std::vector` instead of `std::vector`, supporting the storage of coordinates with different dimensions, (https://github.com/dbaston/libgeos/tree/concrete-coordseq-buf), or - backed either by...

> Doesn't it have a bearing on whether CoordinateSequences are better off using a vector rather than a fixed-size buffer? What would be the advantage of a fixed-size buffer over...

> Via a method `get(Coordinate)`, which copies the ordinate values into the provided `Coordinate`. I expect we'd wind up with `get(CoordinateXY)`, get(CoordinateXYM)` and getCoordinate(CoordinateXYZM)` too, for situations in which they...

> Didn't you have a templated branch packing higher dimensional coordinates into a different coordinate buffer as an optional thing? Yes, that's the second implementation from left in the plots....

> Couldn't it allow return-by-reference of a `CoordinateXY`? Which is most of the use. Yes, you could avoid a copy for the 2D case. To back up, we are fundamentally...

Yes, I think a future GEOS mostly uses `CoordinateXY` and those values are stored without a bunch of interspersed `NaN` values in a `CoordinateSequence`. The implementations I am working with...

Superseded by #721

Thanks for digging in and documenting all this. I'll have time to start joining the effort next month - looking forward to it! Do you have any thoughts on the...

I think the `shared_ptr` would allow us to cleanly handle the case of the "lonely CoordinateSequence" by providing the ability to have constructs like `coords_out = remove_repeated_points(coords_in)` where `coords_out` and...

Is there a way to apply this to all of our targets without copy-paste? (benchmarks, tests, etc.)