[postgis-users] ST_CurveToLine and ST_LineToCurve problems

[Marcin Mionskowski]

Hi Paul,
I'm very grateful for your response.
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).
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?
This is important for me, as in my use case, I need very specific number of
segments in a quadrant (90).

śr., 10 lis 2021 o 16:40 Paul Ramsey <pramsey at cleverelephant.ca> napisał(a):

>
>
> > On Nov 10, 2021, at 7:24 AM, Marcin Mionskowski <
> mionskowskimarcin at gmail.com> wrote:
> >
> > So... Are what I have described bugs or is it supposed to work this way?
>
> 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!
>
> P
> _______________________________________________
> postgis-users mailing list
> postgis-users at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20211112/c323fe04/attachment.html>