ST_LineToCurve turns squares into circles

[strk]

When passed a square linestring (5 vertices), ST_LineToCurve returns a circle. The result is conceptually valid, but it is unlikely that the user wants that. Maybe the function should accept a parameter with the minimum number of segments per quadrant for a curve approximation to be considered such. What do other people think about that ?

In the case of the square we'd have a single segment per quadrant.

We could maybe even refuse to consider such a thing a curve by default, considering that the default segments per quadrant in ST_CurveToLine is 32

[strk]

The same happens with triangles, for the same reason. The below image shows the input to ST_LineToCurve in green and the output (segmentized again for display purposes) in brown.

Note that the triangle input was itself coming from the segmentation of a circularstring.

[robe]

If it accepts a parameter has to wait for 2.2

[strk]

I'm thinking for a start it won't accept a parameter, but will hard-code a minimum number of required edges to define an arc. Do you see any problem with that ?

[robe]

It's only a problem if you consider the prior behavior a bug that needs fixing. Sounds like you are saying its simply not the expected behavior (though not a bug), you as a user would expect. Then you are changing behavior in a micro (that is not a bug) — a bit of a no no.

It's also an issue if it requires a fair amount of changing. We don't have it in our guideliines, but there is an unknown point in complexity of code where we have to say let old dogs lie.

[strk]

I have the change ready. You may compare this with the result from #2412 where a LINESTRING with only 3 vertices would have raised an exception. Also see #2407 which is about symmetricity of LineToCurve and CurveToLine and ask yourself what would you want from a LineToCurve. Is it a geometric excercise ? In that case why not also returning a circle when given a 3-vertex linestring ? Is that a way to save vertices while still retaining the original shape ? In that case for sure a circle is _not_ close enough to your starting triangle or square, is it ?

I keep thinking there should be a minimum set of requirements to turn something to a curve. The number of edges ? The difference in extent from the original ? We have two cases of approximated curves produced by PostGIS. One is ST_CurveToLine which uses a default of 32 edges per quadrant, the other is ST_Buffer which uses a default of 8 edges per quadrant. Can't we safely use 2 segments per quadrant as the hardcoded bare minimum ?

[strk]

I've committed my ready change in trunk with r11769, so you can maybe try it against your curves.

[strk]

The code is now also in 2.1.0 with r11771. I'll keep the ticket open to consider backporting to 2.0.4, would like to hear from Paul and Olivier about this.

[pramsey]

I can live w/ this.

[strk]

Paul: with this being only in 2.1 or with this also going to 2.0 ?

By the way, see also #2423 for another case of straight lines becaming curves. I start thinking the 1.5 approach (using angles) was better, what was the rationale for switching to distance-from-center ?

[strk]

r11780 backports this change to 2.0, with permission of Paul on IRC

[strk]

r11794 in trunk, r11796 in 2.1 and r11798 in 2.0 computes the correct number of quadrants of an arc, also fixing the case of U-shaped lines turning into circles.

[strk]

actually, quadrant computation is still wrong —- I'll need some help with this, can't figure out how to tell the angle of the actual arc. It looks like sign and orientation is getting in my way…

[strk]

Figured, it was lw_segment_side possibly returning other negative values, not only -1 as the code assumed. This is now fixed with r11800 for 2.0 branch (2.0.4), r11801 for trunk (2.2.0) and r11802 in 2.1 branch (2.1.0)