BufferOp / Offset Curve producing additional points

[maxomous]

After producing an offset curve from a set of points, an additional 2 points are created at the beginning and end of the offset curve.

I recently added a question to stack overflow, it's probably better to just link that as there are images, an explanation and my code also:
Link to Stack Overflow

I'm unsure if this is something I have coded incorrectly or whether it is a bug within the geos?

Thanks in advance,
Max

[pramsey]

This is a ... not a "bug" necessarily but a "deficiency" in the offset curve algorithm as it currently exists. @dr-jts is re-working offset curve generation so that in 3.11 we should have something that is more "rational" across all cases.

Note that there is no "one true offset curve" for any given input, at least for inputs with some complexity to them (overlaps and crossings and end points that are close to rest of the line), so that the "right" curve is will always be a bit at issue.

In the meantime, you might find that adding a very small amount of randomness to your inputs before generating the offset curve has an effect. Basically you're seeing that the existing approach is kind of brittle in how it selects edges to add to the curve, and just "shaking things around" a little can change the outputs.

This is a long-winded way to say "we are not going to fix the current implementation in 3.10 and earlier" because we're getting a fresh one in 3.11.

[pramsey]

See also #477

[maxomous]

Thanks for the quick response :)
Good idea about the randomness, that's not something I had thought of and will implement that for the time being.
Do you have a rough eta of when you expect 3.11 to be released out of interest?
thanks

[pramsey]

About 10 months, we're on an annual cadence. New implementation of offset curves could be much sooner, so you could run off main as necessary.

[maxomous]

great, thanks for your help and good luck with it all!

[dr-jts]

The OffsetCurve code has landed in JTS (locationtech/jts#810), and should be in GEOS soon. As shown below, it doesn't have the issue of additional lines at the end.

However, currently it only supports a round join type. Is the mitred join type shown in the SO images important? I'm not sure how feasible it will be to support mitred joins in the new code base.

[maxomous]

Oh great news.
It's not an issue for me, round is perfect

[dr-jts]

This should be fixed by #530. Are you able to verify?

[maxomous]

Hi Martin, I've just given this a try but it seems to produce the same issue.
Just to confirm, here were my steps:

• I removed the current version libgeos and checked that my program would not compile
• I then downloaded the 810 branch from https://github.com/pramsey/geos/tree/main-jts-810
• And followed the instructions within install.md
• Recompiled my program

Here is the result:

Edit: It's worth pointing out, I'm using the c api

[pramsey]

Can you paste your program into GH here? Can't be very long, right? :)

[dr-jts]

Can you paste your program into GH here?

The code is here.

At first I suspected that the C++ code was being used directly, but it is in fact using the C API, which should produce the correct answer.

@maxomous this code is now in main, so you should use that branch for testing.

[dr-jts]

When I try this with main using geosop, I get the expected result:

bin/geosop -a "LINESTRING (20 80, 80 80, 80 20, 20 20)" -f wkt offsetCurve 10
bin/geosop -a "LINESTRING (20 80, 80 80, 80 20, 20 20)" -f wkt OLDoffsetCurve 10

[pramsey]

Good, this is what I wondered. Reporter's env is probably still linking old library somewhere. The new code is in 'main' so you don't need to pull the old working branch.

[maxomous]

You solved it! There were some old files which weren't removed correctly. I've now pulled the main branch and it seems to have resolved the issue. Appreciate the help and great work!