ST_CurveToLine extended API proposal

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

ST_CurveToLine extended API proposal

Sandro Santilli-3
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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/postgis-devel
Reply | Threaded
Open this post in threaded view
|

Re: ST_CurveToLine extended API proposal

Tom van Tilburg-2
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 <[hidden email]> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/postgis-devel


_______________________________________________
postgis-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/postgis-devel
Reply | Threaded
Open this post in threaded view
|

Re: ST_CurveToLine extended API proposal

Sandro Santilli-3
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 <[hidden email]> 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
> > [hidden email]
> > https://lists.osgeo.org/mailman/listinfo/postgis-devel
_______________________________________________
postgis-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/postgis-devel
Reply | Threaded
Open this post in threaded view
|

Re: ST_CurveToLine extended API proposal

Paul Ramsey-3
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 <[hidden email]> 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 <[hidden email]> 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
> > [hidden email]
> > https://lists.osgeo.org/mailman/listinfo/postgis-devel
_______________________________________________
postgis-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/postgis-devel


_______________________________________________
postgis-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/postgis-devel
Reply | Threaded
Open this post in threaded view
|

Re: ST_CurveToLine extended API proposal

Sandro Santilli-3
On Tue, Jun 13, 2017 at 09:06:53AM -0700, Paul Ramsey wrote:
> 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.

All-equal-lengths is now implemented in the PR:
https://gitlab.com/postgis/postgis/merge_requests/3

As of commit b9599af94321d7c9585d59bd5f9202975d7768b5

It'll be done when passing LW_LINEARIZE_FLAG_SYMMETRIC flag
to this new liblwgeom function:

   LWGEOM* lwcurve_linearize(const LWGEOM *geom, double tol,
                             LW_LINEARIZE_TOLERANCE_TYPE type, int flags);

Backward compatibility is retained (lwgeom_stroke calls
lwcurve_linearize with flags and types retaining backward
compatibility).

--strk;
_______________________________________________
postgis-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/postgis-devel
Reply | Threaded
Open this post in threaded view
|

Re: ST_CurveToLine extended API proposal

Tom van Tilburg-2
Superb! Really happy with this new behaviour :)

On Mon, Jun 19, 2017 at 11:05 AM, Sandro Santilli <[hidden email]> wrote:
On Tue, Jun 13, 2017 at 09:06:53AM -0700, Paul Ramsey wrote:
> 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.

All-equal-lengths is now implemented in the PR:
https://gitlab.com/postgis/postgis/merge_requests/3

As of commit b9599af94321d7c9585d59bd5f9202975d7768b5

It'll be done when passing LW_LINEARIZE_FLAG_SYMMETRIC flag
to this new liblwgeom function:

   LWGEOM* lwcurve_linearize(const LWGEOM *geom, double tol,
                             LW_LINEARIZE_TOLERANCE_TYPE type, int flags);

Backward compatibility is retained (lwgeom_stroke calls
lwcurve_linearize with flags and types retaining backward
compatibility).

--strk;
_______________________________________________
postgis-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/postgis-devel


_______________________________________________
postgis-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/postgis-devel