[postgis-devel] ST_CurveToLine extended API proposal

[Paul Ramsey]

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.

P

On Tue, Jun 13, 2017 at 8:25 AM, Sandro Santilli <strk at kbt.io> wrote:

> On Tue, Jun 13, 2017 at 11:27:10AM +0200, Tom van Tilburg wrote:
> > For what it's worth: I noticed that the old behaviour of
> segs_per_quadrant
> > caused some topologies to break because the segments were not of equal
> > length. When polygons are neighbouring eachother in a topological manner,
> > the new segments vertices will not align with the neighbour when running
> > ST_CurveToLine on both polygons, since the line direction is opposite.
> > (GDAL does it correct, making every segment in the former curve of equal
> > length).
> > If this behaviour can be tackled in new functionality that would be
> great.
>
> I think the "balanced" argument would take care of that.
>
> I was actually thinking of making first and last segment of
> equal length rather than all segments of the same length, but
> your suggestion seems indeed better. I don't think we need
> two different policies, what do you think ?
>
> --strk;
>
> >
> > On Tue, Jun 13, 2017 at 11:12 AM, Sandro Santilli <strk at kbt.io> wrote:
> >
> > > I've started work on extended functionality for ST_CurveToLine [1]
> > > to allow for specifying max-error instead of segments-per-quadrant [2]
> > > and balancing of output segments [3].
> > >
> > > [1] https://postgis.net/docs/ST_CurveToLine.html
> > > [2] https://trac.osgeo.org/postgis/ticket/2464
> > > [3] https://trac.osgeo.org/postgis/ticket/3772
> > >
> > > Current API is:
> > >
> > >   ST_CurveToLine(geom) -- defaults to 32 segs-per-quadrant
> > >   ST_CurveToLine(geom, integer segs_per_quadrant)
> > >
> > > The proposed new API would be:
> > >
> > >   ST_CurveToLine(geom geometry,
> > >           tolerance float8 = 32,
> > >           tolerance_interpretation int = 0,
> > >           balanced bool=true)
> > >
> > > The tolerance_intepretation parameter could initially
> > > support these values:
> > >
> > >   0 - segments per quarter circle
> > >   1 - maximum distance beween segment and curve
> > >
> > > Leaving the door open to futher extensions (for example
> > > QGIS also supports "maximum angle between segments").
> > >
> > > The default values would also allow for the new signature
> > > to replace the existing ones, so to have a single signature.
> > >
> > > Of course the code would then need to perform some consistency
> > > checking, like not accepting a non-integer value as tolerance
> > > when "segments-per-quarter-cirlce" interpretation is requested.
> > >
> > > What do you think about the proposal ?
> > >
> > > --strk;
> > > _______________________________________________
> > > postgis-devel mailing list
> > > postgis-devel at lists.osgeo.org
> > > https://lists.osgeo.org/mailman/listinfo/postgis-devel
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20170613/22f355e0/attachment.html>