<div dir="ltr"><div class="gmail_default" style="font-family:monospace">Hi Paul,<br>I'm very grateful for your response.<br>You are right with "cheating" when it comes to non-equal results of ST_LineToCurve on "supposedly" same input, which I described as my second problem (in this case I would use the buffer with minimal number of segments anyway).<br>But that doesn't *fully* explain the first problem. From my understanding, the algorithm (1) needs to "know" how large fragment of a circle is represented by the input curve, (2a) divides full quadrants into speccified number of segments and (2b) divides the last quadrant-part into proportional number of segments. It looks like the problem lies within the 2b step (at least in my test example with full circles). When algorithm divides quadrants into very specific number of segements (61*2^n, 197*2^n, 7^3*2^n and so on), the last full quadrant is represented by "correct" number of segments. In any other cases, one segment is missing. So, the true question seams to be, why are these cases different? What is the nominator value, that  dividing by 61 "works", and by 60 doesn't? Or how is the length of the last part of a curve determined, that the denominator value matters?<br>This is important for me, as in my use case, I need very specific number of segments in a quadrant (90).</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">śr., 10 lis 2021 o 16:40 Paul Ramsey <<a href="mailto:pramsey@cleverelephant.ca">pramsey@cleverelephant.ca</a>> napisał(a):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On Nov 10, 2021, at 7:24 AM, Marcin Mionskowski <<a href="mailto:mionskowskimarcin@gmail.com" target="_blank">mionskowskimarcin@gmail.com</a>> wrote:<br>
> <br>
> So... Are what I have described bugs or is it supposed to work this way?<br>
<br>
Mostly things are supposed to work this way. Remember you are "cheating", you see the original input run it through linetocurve/curvetoline, whereas the algorithm (particularly the linetocurve one) has only what it sees coming in to try and figure out the "right" curve. This particular piece of code has been through multiple revisions and tweaking and at least a couple completely different algorithmic approaches, so probably any changes to fix "case a" will in turn destabilize other cases. I am loath to touch it every again, but maybe there's someone else for whom the problem calls out to them!<br>
<br>
P<br>
_______________________________________________<br>
postgis-users mailing list<br>
<a href="mailto:postgis-users@lists.osgeo.org" target="_blank">postgis-users@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/postgis-users" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-users</a><br>
</blockquote></div>