<div dir="ltr">All equal lengths has nice properties in terms of both regular lengths and regular angles between segments. If you can do it, I don't really see the point in other "lesser" options. Also, am fine WRT to the API as long as we preserve the backwards compatibility, as we do know that lots of people use these functions, so behavior changes on the old API *will* cause complaints.<div><br></div><div>P</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 13, 2017 at 8:25 AM, Sandro Santilli <span dir="ltr"><<a href="mailto:strk@kbt.io" target="_blank">strk@kbt.io</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, Jun 13, 2017 at 11:27:10AM +0200, Tom van Tilburg wrote:<br>
> For what it's worth: I noticed that the old behaviour of segs_per_quadrant<br>
> caused some topologies to break because the segments were not of equal<br>
> length. When polygons are neighbouring eachother in a topological manner,<br>
> the new segments vertices will not align with the neighbour when running<br>
> ST_CurveToLine on both polygons, since the line direction is opposite.<br>
> (GDAL does it correct, making every segment in the former curve of equal<br>
> length).<br>
> If this behaviour can be tackled in new functionality that would be great.<br>
<br>
</span>I think the "balanced" argument would take care of that.<br>
<br>
I was actually thinking of making first and last segment of<br>
equal length rather than all segments of the same length, but<br>
your suggestion seems indeed better. I don't think we need<br>
two different policies, what do you think ?<br>
<br>
--strk;<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> On Tue, Jun 13, 2017 at 11:12 AM, Sandro Santilli <<a href="mailto:strk@kbt.io">strk@kbt.io</a>> wrote:<br>
><br>
> > I've started work on extended functionality for ST_CurveToLine [1]<br>
> > to allow for specifying max-error instead of segments-per-quadrant [2]<br>
> > and balancing of output segments [3].<br>
> ><br>
> > [1] <a href="https://postgis.net/docs/ST_CurveToLine.html" rel="noreferrer" target="_blank">https://postgis.net/docs/ST_<wbr>CurveToLine.html</a><br>
> > [2] <a href="https://trac.osgeo.org/postgis/ticket/2464" rel="noreferrer" target="_blank">https://trac.osgeo.org/<wbr>postgis/ticket/2464</a><br>
> > [3] <a href="https://trac.osgeo.org/postgis/ticket/3772" rel="noreferrer" target="_blank">https://trac.osgeo.org/<wbr>postgis/ticket/3772</a><br>
> ><br>
> > Current API is:<br>
> ><br>
> >   ST_CurveToLine(geom) -- defaults to 32 segs-per-quadrant<br>
> >   ST_CurveToLine(geom, integer segs_per_quadrant)<br>
> ><br>
> > The proposed new API would be:<br>
> ><br>
> >   ST_CurveToLine(geom geometry,<br>
> >           tolerance float8 = 32,<br>
> >           tolerance_interpretation int = 0,<br>
> >           balanced bool=true)<br>
> ><br>
> > The tolerance_intepretation parameter could initially<br>
> > support these values:<br>
> ><br>
> >   0 - segments per quarter circle<br>
> >   1 - maximum distance beween segment and curve<br>
> ><br>
> > Leaving the door open to futher extensions (for example<br>
> > QGIS also supports "maximum angle between segments").<br>
> ><br>
> > The default values would also allow for the new signature<br>
> > to replace the existing ones, so to have a single signature.<br>
> ><br>
> > Of course the code would then need to perform some consistency<br>
> > checking, like not accepting a non-integer value as tolerance<br>
> > when "segments-per-quarter-cirlce" interpretation is requested.<br>
> ><br>
> > What do you think about the proposal ?<br>
> ><br>
> > --strk;<br>
> > ______________________________<wbr>_________________<br>
> > postgis-devel mailing list<br>
> > <a href="mailto:postgis-devel@lists.osgeo.org">postgis-devel@lists.osgeo.org</a><br>
> > <a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/postgis-devel</a><br>
______________________________<wbr>_________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org">postgis-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/postgis-devel</a></div></div></blockquote></div><br></div>