Opened 9 years ago

Closed 9 years ago

#2423 closed defect (fixed)

[REGRESSION] ST_LineToCurve gets semicircle wrong

Reported by: strk Owned by: pramsey
Priority: medium Milestone: PostGIS 2.0.4
Component: postgis Version: 2.0.x
Keywords: curves Cc:


Passing a semicircle polygon to ST_LineToCurve in 2.0.x results in a full circle with about half the area outside of the original lienear shape and not covering half of the original shape.

Result from 1.5.x is perfect.

Attachments (1)

curve_from_semicircle_line.png (16.3 KB ) - added by strk 9 years ago.

Download all attachments as: .zip

Change History (8)

by strk, 9 years ago

comment:1 by strk, 9 years ago

I think the problem is with 2.0.x only considering distance from circumcenter rather than also angle between segments composing it. If angles were considered, like in the 1.5.x times, it will be clear that the last sement (the horizontal one at the bottom) would form a much smaller angle than the precedent ones.

comment:2 by strk, 9 years ago

Keywords: curves added

comment:3 by strk, 9 years ago

Beside breaking the arc at the appropriate place (when angle between edges changes drastically) I think we should also avoid to define circles with a single curve, because such a curve would effectively be only defined by 2 points (as first and last would be the same) thus allowing for infinite arcs. When a circle is detected (which would be wrong, in this case) the code should produce an output composed by two semicircle curves (but this is probably the topic for another ticket).

comment:4 by strk, 9 years ago

Or, by convention, we could assume that the control point of a full circle must always be on the other side of the diameter starting from the first/last point of the curve. In this case the control point should then be 10,0 rather than 0,10.

The actual output:

 CURVEPOLYGON(CIRCULARSTRING(-10 0,-3.73640463187386e-14 10,-10 0))

The input:

st_intersection(st_buffer(st_point(0,0),10),'POLYGON((-10 0,10 0,10 10,-10 10,-10 0))')

comment:5 by strk, 9 years ago

The current code takes the num_points/2 vertex as the control point, which is just a guess. A better guess would be the vertex which the least difference in distance from last and first points. The ideal control point is equidistant from endpoints.

comment:6 by strk, 9 years ago

I've a tentative fix for this that checks angle between consecutive arc edges. Looks promising. The only failing test is for ticket #183 but the obtained result with the patch is actually what the reporter of #183 was hoping for (a circularstring followed by a linestring, in a compound curve) so I'd say it's a more correct output.

comment:7 by strk, 9 years ago

Resolution: fixed
Status: newclosed

Fix committed in trunk (2.2) as r11778, 2.1.0 branch as r11779 and 2.0 branch (2.0.4) as r11781

Note: See TracTickets for help on using tickets.