Offset curve has Weird Geometry

[MrShutCo]

Output of offsetting this curve by 15 with CAP_ROUND and JOIN_ROUND is unexpected

LINESTRING(292671.05 7336734.42,292624.85 7336739.72,292623.53 7336739.92,292622.36 7336740.2,292621.35 7336740.57,292620.94 7336740.78,292620.61 7336740.97,292620.33 7336741.14,292620.13 7336741.29,292619.79 7336741.57,292619.48 7336741.86,292619.34 7336742.01,292619.21 7336742.17,292619.09 7336742.34,292618.98 7336742.51,292618.8 7336742.88,292618.63 7336743.25,292618.57 7336743.43,292618.52 7336743.58,292618.48 7336743.71,292618.46 7336743.8,292618.44 7336743.98,292618.42 7336744.15,292618.41 7336744.33,292618.4 7336744.51,292618.39 7336744.69,292618.38 7336744.88,292618.38 7336744.91,292618.38 7336744.95,292618.38 7336744.99,292618.38 7336745.02,292618.38 7336745.06,292618.38 7336745.1,292618.38 7336745.13,292618.38 7336745.17,292618.38 7336745.21,292618.38 7336745.25,292618.38 7336745.43,292618.41 7336746.92)

Which gives

LINESTRING(292672.7595667329 7336749.322260955,292626.8289702739 7336754.5913553545,292626.5791762319 7336754.629202936,292626.5097220095 7336754.654646562,292626.50454360223 7336754.64051091,292626.4042523117 7336754.65570656,292626.5015777726 7336754.632414997,292626.44602173776 7336754.480762037,292628.06232136535 7336753.77393037,292629.15317889326 7336753.036285378,292629.3464127592 7336752.884382651,292629.7456107097 7336752.533905098,292630.23746757495 7336752.041483207,292630.77071670454 7336751.429334497,292631.26624786 7336750.77544772,292631.44290077855 7336750.514153615,292632.18637824676 7336749.195972605,292632.6413907597 7336748.0441531595,292632.7640483846 7336747.639042543,292632.95704258484 7336746.627106525)

And looks like

Is this expected behaviour?

[pramsey]

Yes, looks fine to me. Large offsets are always going to be a bit weird, and you've got a 90 degree turn there that is way below the radius you are using, so... if you want to see "why", generate a bunch of curves starting with a small offset and working your way up.

[MrShutCo]

Ah right, doing that made it a lot more clear whats going on. I extended the line farther in that direction and it gave a better result.

One more question if you don't mind, but do you have any tips about how to keep a smooth curve like this (same as above) to keep its smoothness while offsetting? Would I just need to make the turning radius of the first curve to be larger than the offset amount or is there something else?

Thanks again!

[pramsey]

Yeah, interior corners are going to necessarily end up sharper than exterior ones... that's kind of the nature of the best, yeah?

[dr-jts]

@MrShutCo what version of GEOS are you using?

In GEOS 3.11 offsetting your input by 15 (using default cap and join, which I believe are CAP_ROUND and JOIN_ROUND) produces:

[MrShutCo]

@dr-jts My bad, I forgot that my code is negating the offset so its actually -15.

But my version is 3.11.1, and I'm writing code in Go and using a C-wrapper that eventually calls a function called _cgo_5f6ded1871a9_Cfunc_GEOSOffsetCurve_r. The wrapper itself might be outdated, but if it points to the same function then I don't see why it would be any different.

[dr-jts]

Running this in GEOS 3.11 (HEAD) with offset -15:

bin/geosop -a "LINESTRING(292671.05 7336734.42,292624.85 7336739.72,292623.53 7336739.92,292622.36 7336740.2,292621.35 7336740.57,292620.94 7336740.78,292620.61 7336740.97,292620.33 7336741.14,292620.13 7336741.29,292619.79 7336741.57,292619.48 7336741.86,292619.34 7336742.01,292619.21 7336742.17,292619.09 7336742.34,292618.98 7336742.51,292618.8 7336742.88,292618.63 7336743.25,292618.57 7336743.43,292618.52 7336743.58,292618.48 7336743.71,292618.46 7336743.8,292618.44 7336743.98,292618.42 7336744.15,292618.41 7336744.33,292618.4 7336744.51,292618.39 7336744.69,292618.38 7336744.88,292618.38 7336744.91,292618.38 7336744.95,292618.38 7336744.99,292618.38 7336745.02,292618.38 7336745.06,292618.38 7336745.1,292618.38 7336745.13,292618.38 7336745.17,292618.38 7336745.21,292618.38 7336745.25,292618.38 7336745.43,292618.41 7336746.92)" -f wkt offsetCurve N-15

produces this:

LINESTRING (292672.7595667329 7336749.322260955, 292631.53009245027 7336754.052049131)

I'm not sure why you're seeing a different result. If you are passing explicit CAP and JOIN parameters, perhaps that's causing a problem? Can you call the OffsetCurve routine with default parameters?

What Go wrapper are you using?

[dr-jts]

Aha... running via the C API produces what you are seeing:

    checkOffset(
        "LINESTRING (292671.05 7336734.42, 292624.85 7336739.72, 292623.53 7336739.92, 292622.36 7336740.2, 292621.35 7336740.57, 292620.94 7336740.78, 292620.61 7336740.97, 292620.33 7336741.14, 292620.13 7336741.29, 292619.79 7336741.57, 292619.48 7336741.86, 292619.34 7336742.01, 292619.21 7336742.17, 292619.09 7336742.34, 292618.98 7336742.51, 292618.8 7336742.88, 292618.63 7336743.25, 292618.57 7336743.43, 292618.52 7336743.58, 292618.48 7336743.71, 292618.46 7336743.8, 292618.44 7336743.98, 292618.42 7336744.15, 292618.41 7336744.33, 292618.4 7336744.51, 292618.39 7336744.69, 292618.38 7336744.88, 292618.38 7336744.91, 292618.38 7336744.95, 292618.38 7336744.99, 292618.38 7336745.02, 292618.38 7336745.06, 292618.38 7336745.1, 292618.38 7336745.13, 292618.38 7336745.17, 292618.38 7336745.21, 292618.38 7336745.25, 292618.38 7336745.43, 292618.41 7336746.92)",
        "LINESTRING (292672.7595667329 7336749.322260955, 292631.53009245027 7336754.052049131)",
        -15, 8, GEOSBUF_JOIN_ROUND, 0,
        0.000001
        );

More investigation required...

[MrShutCo]

Changed it to pass in just the default and it gives this:

We're using a forked version of https://github.com/paulsmith/gogeos it seems, which looking at now I'm kinda surprised just how old it is lol.

Although seeing that makes me think its on the geos side...

[dr-jts]

Got it... it's a small bug in the C-API GEOSOffsetCurve_r function to do with initializing the endcap style (which should be left as default, since it isn't actually used).

Will fix soon, and backport to 3.11.

[strk]

More weird offset curves here: qgis/QGIS#53165 (comment)