[postgis-devel] Proposal: ST_Overlay function

[Martin Davis]

Excellent, Stephen, thanks for the feedback.

On Sun, Jul 25, 2021 at 2:58 PM Stephen Mather <stephen at smathermather.com>
wrote:

> Hi Martin,
>
> You know my thoughts on this: yes please! Lots of use cases, and much
> better than the current (but clever) approach linked to.
>
> Cheers,
> Best,
> Steve
>
>
>
> On Wed, Nov 18, 2020 at 10:22 PM Martin Davis <mtnclimb at gmail.com> wrote:
>
>> 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/adb65584/attachment.html>