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

[Brendan Ward]

Very excited about progress on this front!  Thanks for the update Martin.

I think the idea of a separate coverage type in the C API captures my
thoughts as well.

I anticipate wanting to run chained operations (esp. simplify, precision
reduction, smoothing) on coverages.  Having final outputs (e.g., coverage
=> polygons) relate 1:1 to the input polygons so we can re-attach
associated data will be essential; I think it will be OK for the
intermediate coverage to be its own collection type and not relatable back
1:1.  I.e., I don't anticipate wanting to simplify elements of the coverage
differently from each other.

Should the signature for Union instead be Coverage -> Coverage?  Then it
could also be used in a chain of operations affecting coverages.
Then a separate function for Coverage -> Polygonal geometry (since it could
be used for more than just union)

On Wed, Sep 7, 2022 at 7:29 AM Daniel Baston <dbaston at gmail.com> wrote:

> 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
>>
> _______________________________________________
> geos-devel mailing list
> geos-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel
>


-- 
Brendan C. Ward
Owner | Lead Software Engineer
Astute Spruce, LLC
astutespruce.com
541-250-9544
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geos-devel/attachments/20220907/91e736ad/attachment.htm>