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

[Paul Ramsey]

> On Sep 7, 2022, at 3:50 PM, Martin Davis <mtnclimb at gmail.com> wrote:
> 
> You read my mind.  I'm fine with an additional type in PostGIS.
> 
> Along the lines with what Dan Baston said, the idea of having a special
> coverage type that multiple operations can be applied to is very appealing
> to me.
> 
> But not sure how much extra overhead or difficulty that would cause for
> other projects consuming such a new type.
> Maybe for some it can have a mutator to convert it to a polygon array or
> something, for projects that can't handle consuming additional types.
> 
> I'm actually thinking the opposite!  My goal is to provide operations which can be used to process sets of records in PostGIS with polygonal geometry, which *implicity* form a coverage.  That fits in better with the relational and SQL paradigm, I think.  In particular, coverage polygon attributes are simply represented by the table rows.  By using window functions coverage operations can run over sets of rows and produce new values for the geometry in each row (for example:
> 
> - linework indicating coverage errors
> - a coverage-clean version of the input
> - a simplified version of the input

There a half-way meeting point in here somewhere, in which some of the operations that are quite intense in the postgis_topology (add an edge to an existing topology within a tolerance, add a polygon to an existing topology) might be delegated to GEOS if the API was rich enough to round-trip the structures. The Oracle topology module has/had the idea of a "working area", so that a portion of the structure could be pulled out and edited (with topology rules) and then stuffed back in and re-integrated very cheaply (presumably because the edges of the "working area" were held invariant in the operations. The upside of such an approach would be the "holy grail" of larger-than-memory coverages that could still be operated on. The downside is complexity. I think we'll find that enough use cases fit inside a "polygon[] -> (opaque engine) -> polygon[]" that the limitations are generally worth putting up with.

P


> 
>   
> _______________________________________________
> geos-devel mailing list
> geos-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel