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

[Daniel Baston]

Lots of useful stuff here!

I would prefer a specific coverage data type, because it more clearly
captures intent, allows
preservation of structural information (or other data we haven't yet
anticipated) between function calls, and
results in function signatures that are simpler those associated with
geometry arrays, e.g.

GEOSPolygonCoverage* GEOSCoverageSimplify(GEOSPolygonCoverage* in, double
tol);

vs

int GEOSCoverageSimplify(GEOSGeometry* in, size_t ngeom_in, GEOSGeometry**
out, size_t* ngeom_out, double tol);

For cleanup, it would also be cleaner to call

GEOSCoverageDestroy(coverage);

rather than

for (size_t i = 0; i < ngeoms; i++) {
     GEOSGeom_destroy(coverage[i]);
GEOSFree(coverage)

although we could write a utility function around the latter.

I think some chained operations may not be uncommon, e.g.;

create coverage -> validate coverage -> simplify coverage -> reduce
precision of coverage.

It may be useful to be able to define owning and non-owning variants of
coverages.

Another (probably unpopular) option is to define a polygon coverage as
another subtype of Geometry, and use
our existing API to manipulate it (GEOSisValid, GEOSSimplify, etc.)

Dan


On Tue, Sep 6, 2022 at 5: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
> _______________________________________________
> geos-devel mailing list
> geos-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geos-devel/attachments/20220907/f4a8fc32/attachment-0001.htm>