<div dir="ltr"><div dir="ltr"></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 26, 2021 at 1:14 AM Дорофей Пролесковский <<a href="mailto:me@komzpa.net">me@komzpa.net</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">When developing Global Map for wargaming we called it "Deoverlap".</div></blockquote><div>That is certainly descriptive - but "overlay" I think is more familiar in the GIS world.</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"><div><br></div><div>Another useful similar thing is pprepair, which is Planar Partition Repair. (<a href="https://github.com/tudelft3d/pprepair" target="_blank">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></blockquote><div> </div><div>Yes, pprepair or some similar kind of coverage cleaning capability would be very useful. </div><div><br></div><div>Is it possible to have a set-returning aggregate function in Postgres? Are you thinking the set would just have a schema just containing a geometry field? I"m not sure what else could go in there, given the need for a fixed schema. Perhaps a flag indicating which source input a given polygon came from (A or B or both)? Possibly even a pair of integer ids, to allow fast joining back to inputs if they carried ids as well?</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"><div><br>To me this logically sounds like the way we had ST_VoronoiPolygons organized. </div></div></blockquote><div><br></div><div>Right - it returns a GeometryCollection of polygons. So yes, this would be the same pattern. But of course would be nice to implement a richer return value, if that's possible (as discussed above).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">чт, 19 нояб. 2020 г. в 06:22, Martin Davis <<a href="mailto:mtnclimb@gmail.com" target="_blank">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>
_______________________________________________<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></div>