[postgis-devel] ST_CurveToLine extended API proposal

Tom van Tilburg tom.van.tilburg at gmail.com
Tue Jun 13 02:27:10 PDT 2017


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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20170613/65d49f30/attachment.html>


More information about the postgis-devel mailing list