Opened 9 years ago

Closed 9 years ago

#2420 closed defect (fixed)

ST_LineToCurve turns squares into circles

Reported by: strk Owned by: strk
Priority: medium Milestone: PostGIS 2.0.4
Component: postgis Version: 1.5.X
Keywords: curves, history Cc:


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

Attachments (1)

triangle-to-circle.png (35.3 KB ) - added by strk 9 years ago.

Download all attachments as: .zip

Change History (16)

comment:1 by strk, 9 years ago

Owner: changed from pramsey to strk
Status: newassigned

by strk, 9 years ago

Attachment: triangle-to-circle.png added

comment:2 by strk, 9 years ago

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.

comment:3 by robe, 9 years ago

Milestone: PostGIS 2.0.4PostGIS 2.2.0

If it accepts a parameter has to wait for 2.2

comment:4 by strk, 9 years ago

Milestone: PostGIS 2.2.0PostGIS 2.0.4

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 ?

comment:5 by robe, 9 years ago

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.

comment:6 by strk, 9 years ago

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 ?

comment:7 by strk, 9 years ago

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

comment:8 by strk, 9 years ago

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.

comment:9 by pramsey, 9 years ago

Resolution: fixed
Status: assignedclosed

I can live w/ this.

comment:10 by strk, 9 years ago

Resolution: fixed
Status: closedreopened

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 ?

comment:11 by strk, 9 years ago

Keywords: curves added

comment:12 by strk, 9 years ago

Keywords: history added
Resolution: fixed
Status: reopenedclosed

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

comment:13 by strk, 9 years ago

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.

comment:14 by strk, 9 years ago

Resolution: fixed
Status: closedreopened

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…

comment:15 by strk, 9 years ago

Resolution: fixed
Status: reopenedclosed

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)

Note: See TracTickets for help on using tickets.