[postgis-devel] Proposal: ST_Overlay function

[Martin Davis]

On Mon, Jul 26, 2021 at 1:14 AM Дорофей Пролесковский <me at komzpa.net> wrote:

> When developing Global Map for wargaming we called it "Deoverlap".
>
That is certainly descriptive - but "overlay" I think is more familiar in
the GIS world.

>
> Another useful similar thing is pprepair, which is Planar Partition
> Repair. (https://github.com/tudelft3d/pprepair). I'd love it to be
> considered when inventing a calling convention for this. I always wanted us
> to have a set-returning aggregate function :)
>

Yes, pprepair or some similar kind of coverage cleaning capability would be
very useful.

Is it possible to have a set-returning aggregate function in Postgres?  Are
you thinking the set would just have a schema just containing a geometry
field?  I"m not sure what else could go in there, given the need for a
fixed schema.  Perhaps a flag indicating which source input a given polygon
came from (A or B or both)?  Possibly even a pair of integer ids, to allow
fast joining back to inputs if they carried ids as well?

>
> To me this logically sounds like the way we had ST_VoronoiPolygons
> organized.
>

Right - it returns a GeometryCollection of polygons.  So yes, this would be
the same pattern.  But of course would be nice to implement a richer return
value, if that's possible (as discussed above).


>
> чт, 19 нояб. 2020 г. в 06:22, Martin Davis <mtnclimb at gmail.com>:
>
>> Would it be useful to have a function that performs a full overlay of a
>> set of polygons?
>>
>> The function would accept a single collection (or array) of polygons and
>> overlay them all.  It would return a geometry collection containing all the
>> resultants (but not including any gaps or holes in the input set).
>>
>> This is similar to what is computed by the "node/polygonize" process
>> described here [1] - but with the improvement that areas which are not
>> covered by any input polygon are not included.  And it will be much faster,
>> and simpler to use.
>>
>> [1] http://blog.cleverelephant.ca/2019/07/postgis-overlays.html
>>
>> This is a geometry-only function, so as in the above process it is still
>> necessary to perform a Point-in-Polygon JOIN in order to attach parent
>> attribution to each resultant polygon. To do this the individual polygons
>> in the result have to be extracted using ST_Dump. (A full
>> geometry-attribute overlay is still highly desirable, but currently it's
>> not clear how this should/could operate in Postgres SQL.)
>>
>> The function could be defined as an aggregate, in the same way that
>> ST_Union is an aggregate.
>>
>> I suggest the name ST_Overlay for this function.  It could also be called
>> ST_Intersection, since in a sense it is the opposite of ST_Union. (This is
>> the name that R-sf uses for this process).  However, the analogy is not
>> exact, since unlike the binary ST_Intersection this function returns ALL
>> resultant areas, not just those which are common to every input geometry.
>>
>> This could (and should) be defined for other geometry types too -
>> although it's not clear what the semantics should be.  It's tempting to say
>> that ST_Intersection on lines returns a fully noded and dissolved set of
>> minimal lines - but that is what ST_Union does now.  Perhaps ST_Union
>> should change to returning a *maximal* set of noded lines (i.e. merged
>> node-to-node).
>>
>> Thoughts and comments welcome.
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/postgis-devel
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20210726/b899614d/attachment.html>