[postgis-devel] Proposal: ST_Overlay function

[Дорофей Пролесковский]

When developing Global Map for wargaming we called it "Deoverlap".

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 :)

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

чт, 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20210726/39c047f2/attachment.html>