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

[Martin Davis]

Another consideration is that some coverage operations are more efficient
without creating an explicit Coverage topology structure.  In particular,
Coverage Union does not require a full topological structure, since the
"internal" edges are not used and can be efficiently identified and
discarded without topology being built.

One option is to have two different signatures and implementations for the
Coverage Union operation, one on the suggested Coverage datatype, and a
fast one on a list of polygonal inputs.

On Tue, Sep 6, 2022 at 2:37 PM 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
>
> A key question is how to expose these operations in the GEOS C API.  I see
> two options:
> 1) Model a Polygonal Coverage as an array of simple Polygons (and possibly
> MultiPolygons)
> 2) Provide a Polygonal Coverage datatype (which might contain internal
> topology)
>
> So far I've been favouring #1, both for the C API and for the underlying
> C++ and JTS APIs.  Reasons are:
>
> - Simplicity of use and implementation
> - Some operations (such as validation and cleaning) have to operate on
> non-coverage lists of polygons anyway
> - A potential advantage of having a Coverage data model is that coverage
> operations could be chained without needing to convert back to the simple
> polygon representation - but it's not clear to me that this will be very
> common (and this is not an option for PostGIS, and maybe other downstream
> projects).
> - It seems more in the spirit of the Simple Features philosophy (if that's
> a thing)
>
> Any thoughts or comments on this?
>
> 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.
>
> [1]
> http://lin-ear-th-inking.blogspot.com/2022/07/polygonal-coverages-and-operations-in.html
> [2]
> http://lin-ear-th-inking.blogspot.com/2022/08/validating-polygonal-coverages-in-jts.html
> [3]
> https://github.com/libgeos/geos/commit/62c928c9f37957c62fab8db69e6c8efd26ce4085
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geos-devel/attachments/20220907/80142de4/attachment.htm>