Remove old overlay engine?

[dbaston]

Now that the OverlayNG has been used for three releases, should the code for the previous engine be removed? Leaving it in place means that the code must continue to be maintained to accommodate refactoring, clear static analysis checks, etc.

[dr-jts]

Makes sense. Note that quite a few class deps (e.g. GeometryGraph) are still in use by BufferOp.

[dbaston]

Switching from SnapOverlayOp to OverlayNGRobust in BufferBuilder causes three test failures:

	368 - misc-safe-16595 (Failed)
	369 - misc-safe-16596 (Failed)
	371 - misc-singlesidedbuffer (Failed)

[dr-jts]

Have to do a bit of research to find out if those failures are significant, or just because the output is slightly different.

There's also the issue that the buffer code shares a good chunk of code with the old overlay code (in particular, GeometryGraph. But if we can resolve these failures, it's still nice to chip away the obsolete code where we can.

[pramsey]

Agreed! A worthy change if doable.

[pramsey]

Done?

[dbaston]

Not fully. @dr-jts , does it make sense to you to rework BufferBuilder so that it uses overlayng::Edge and overlayng::PolygonBuilder ?

[dr-jts]

does it make sense to you to rework BufferBuilder so that it uses overlayng::Edge and overlayng::PolygonBuilder ?

i don't think so, for the following reasons:

• Buffer doesn't use an A and B geometry, so the topology labelling and handling is simpler
• I think it's better not to have too much commingling of logic, since that makes both sets of code potentially more brittle

So, it would be nice to purge the use of the GeometryGraph API from BufferOp, but it's going to require a fair amount of rework.