[geos-devel] GEOS C API for Polygonal Coverage operations?

[Martin Davis]

Thanks for the feedback, Nyall.  Comments inline below.

On Tue, Sep 6, 2022 at 3:51 PM Nyall Dawson <nyall.dawson at gmail.com> wrote:

> On Wed, 7 Sept 2022 at 07:37, Martin Davis <mtnclimb at gmail.com> wrote:
> >
> > I've started to build out operations on Polygonal Coverages in JTS ([1],
> [2]).  These will be ported to GEOS (started here with CoverageValidator
> etc in C++ [3]). Hopefully these will be exposed in PostGIS as well (and of
> course other downstream projects).
> >
> > Here's some examples of coverage operations and their geometric
> signatures:
> >
> > - Validation: List of Polygons -> List of linear geometries for invalid
> locations
> > - Cleaning: List of Polygons -> Coverage
> > - Union: Coverage -> Polygonal geometry
> > - Simplification: Coverage -> Coverage
>
> This is exciting, I'm very happy to see this on the horizon. Thank you!
>

Great to hear this is going to be useful.

>
> > If Model #1 is used, what would the C API look like?  Accept a Geometry
> array with a size parameter, and return a Geometry array?  It will likely
> be good to have some support functions to free Geometry arrays too.
>
> This sounds fine to me! A must-have would be that the geometries are
> always guaranteed to be returned in the same order as the input
> geometries, so that we can easily link input->output geometries and
> re-attach non spatial attributes.
>

Yes, that's definitely part of the model - should have mentioned it.

>
> One consideration for the  "Simplification: Coverage -> Coverage" use
> case would be whether only a fixed set of simplification algorithms
> are permitted (eg Visvalingam/Douglas-peucker only), or whether custom
> simplification/modification operations would also be permitted (via
> some callback function or similar). I'd love to see support for custom
> operations, so eg I could write a coverage -> coverage operation which
> applies both simplification and smoothing to the boundaries.
>

At the moment I'm only working on VW simplification, because it reuses a
lot of code already in place.  Pluggable algorithms would be a bit of a
research project, because the requirement of preserving topology and being
performant requires quite a bit of indexing structure to be available.  And
it's not clear how much could be common between different algorithms.

The idea of smoothing is a good one - hadn't thought of that.  Of course,
that might require a different approach yet again to preserve topology...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geos-devel/attachments/20220906/c0bcc646/attachment.htm>