[postgis-devel] Proposal: ST_Overlay function

[rmrodriguez at carto.com]

Hi,

On Thu, Nov 19, 2020 at 4:22 AM Martin Davis <mtnclimb at gmail.com> wrote:
> 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.

The idea looks good in my book.

> 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.

We already have one ST_Intersection (well, actually 14 but all with
the same behaviour), so I much prefer ST_Overlay for the name. I was
also thinking of ST_Cover, but that looks too much like ST_Covers so
not good either, so I went to ST_MinCover or ST_CoverSet, so I ended
up going back to ST_Overlay.

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

Behaviour wise, I would also expect it to return the minimal set. I
don't know if anyone ever wants a maximal set, so replicating the
behaviour of ST_Union for lines and points wouldn't be such a bad
thing, although it could be better (but I don't know how right now).

-- 
Raúl Marín Rodríguez
carto.com