<div dir="ltr">When developing Global Map for wargaming we called it "Deoverlap".<div><br></div><div>Another useful similar thing is pprepair, which is Planar Partition Repair. (<a href="https://github.com/tudelft3d/pprepair">https://github.com/tudelft3d/pprepair</a>). 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 :)</div><div><br>To me this logically sounds like the way we had ST_VoronoiPolygons organized. </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">чт, 19 нояб. 2020 г. в 06:22, Martin Davis <<a href="mailto:mtnclimb@gmail.com">mtnclimb@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Would it be useful to have a function that performs a full overlay of a set of polygons?  <div><br></div><div>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).  <div><br></div><div>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.</div><div><br></div><div>[1] <a href="http://blog.cleverelephant.ca/2019/07/postgis-overlays.html" target="_blank">http://blog.cleverelephant.ca/2019/07/postgis-overlays.html</a></div><div><br></div><div>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.)</div><div><br></div><div>The function could be defined as an aggregate, in the same way that ST_Union is an aggregate. </div><div><br></div><div>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. </div><div><br></div><div>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). </div><div><br></div><div>Thoughts and comments welcome.</div></div></div>
_______________________________________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a></blockquote></div>