<div dir="ltr">Yes, the new OffsetCurve code does not return "inner loops".  That was a deliberate design decision, base on the idea that the offset curve of a single line should itself be a single line.  (Otherwise, how is the client code supposed to know what to do with the multiple lines it gets back?)<div><br></div><div>There's also the new behaviour that for a self-intersecting line the result offset curve stops at the self-intersection (and so is perhaps shorter than might be expected/desired).  This is more a result of me not being able to figure out a workable algorithm to do the alternate thing that was stable and robust against all input situations.  (You can imagine that self-intersecting lines can get infinitely complex...). However, I'll revisit this - perhaps there's a way to change the behaviour in some more tractable cases.</div><div><br></div><div>The underlying issue here is that AFAIK there is no standard definition of what an offset curve should look like.  So there's no basis for disagreement about how the algorithms work - they are just different.  </div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 5, 2022 at 6:53 AM Sandro Santilli <<a href="mailto:strk@kbt.io">strk@kbt.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Paul, I was reading this commit of yours:<br>
<br>
> commit 9b0c432beea50f2b5071a50f6a4e11647c092229<br>
> Author: Paul Ramsey <<a href="mailto:pramsey@cleverelephant.ca" target="_blank">pramsey@cleverelephant.ca</a>><br>
> Date:   Tue Jan 4 14:20:01 2022 -0800<br>
> <br>
>     Revise regression tests so that both pre- and post-GEOS 3.11<br>
>     updates to OffsetCurve will pass.<br>
<br>
[...]<br>
<br>
> +-- SELECT 't14', ST_AsEWKT(ST_Normalize(ST_OffsetCurve(<br>
> +--  'LINESTRING(0 0,0 20, 10 20, 10 10, 0 10)', -2,<br>
> +--  ''<br>
> +-- )));<br>
> +-- SELECT 't15', ST_AsEWKT(ST_Normalize(ST_OffsetCurve(<br>
> +--  'GEOMETRYCOLLECTION(LINESTRING(0 0,0 20, 10 20, 10 10, 0 10),MULTILINESTRING((2 0,2 20, 12 20, 12 10, 2 10),(3 0,3 20, 13 20, 13 10, 3 10)))', -2,<br>
> +--  ''<br>
> +-- )));<br>
<br>
With GEOS 3.11.0dev (unknown hash) from t14 I get the result<br>
which was expected:<br>
<br>
  MULTILINESTRING((2 12,8 12,8 18,2 18,2 12),(2 8,2 0))<br>
<br>
The new GEOS gives:<br>
<br>
  LINESTRING(2 0,2 8)<br>
<br>
Shouldn't the new GEOS result be considered bogus instead ?<br>
<br>
In the ASCII drawing below, you see the input (with arrow<br>
signs showing the direction) and the previous result of the<br>
offset:<br>
<br>
    .--->----.<br>
    | .----, |<br>
    ^ |    | v<br>
    | '----' |<br>
    |---<----'<br>
    |<br>
    ^ |<br>
    | |<br>
    | |<br>
<br>
The new result is basically ONLY returning the vertical open<br>
line on the bottom and completely missing the inner rectangle<br>
on top.<br>
<br>
--strk;<br>
</blockquote></div>