<div dir="ltr">Excellent, Stephen, thanks for the feedback.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jul 25, 2021 at 2:58 PM Stephen Mather <<a href="mailto:stephen@smathermather.com">stephen@smathermather.com</a>> wrote:<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">Hi Martin,<div><br></div><div>You know my thoughts on this: yes please! Lots of use cases, and much better than the current (but clever) approach linked to.</div><div><br></div><div>Cheers,</div><div>Best,</div><div>Steve<br><div><br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 18, 2020 at 10:22 PM Martin Davis <<a href="mailto:mtnclimb@gmail.com" target="_blank">mtnclimb@gmail.com</a>> wrote:<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>
_______________________________________________<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><br>
</blockquote></div>