<div dir="ltr">Either way, the union of a polygonal coverage is a common special case that would benefit from having its own algorithm. I implemented this for PostGIS a couple of years ago, though there didn't seem to be much interest at the time [1]. It's probably a better fit for GEOS anyway. I wrote a fairly ugly Java implementation several years ago [2] that I could re-do to take advantage of recent polygonizer improvements and bring into GEOS.<div><br></div><div>Dan<br><div><br></div><div>[1] <a href="https://lists.osgeo.org/pipermail/postgis-devel/2016-April/025784.html">https://lists.osgeo.org/pipermail/postgis-devel/2016-April/025784.html</a></div></div><div>[2] <a href="https://github.com/dbaston/CoverageOp/tree/master/src/main/java/org/dbaston/coverageop">https://github.com/dbaston/CoverageOp/tree/master/src/main/java/org/dbaston/coverageop</a></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 16, 2019 at 11:06 AM Martin Davis <<a href="mailto:mtnclimb@gmail.com">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">That's good to know, Darafei.   Can you provide a data example that we can use for doing performance testing?<div><br></div><div>I'm not seeing that JTS buffer(0) is slower than union() on a random triangulation.  So perhaps either your dataset has some different characteristic, or possibly GEOS buffer has different performance characteristics to JTS.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 16, 2019 at 5:27 AM Darafei "Komяpa" Praliaskouski <<a href="mailto:me@komzpa.net" target="_blank">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"><div class="gmail_quote"><div>Hello,</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"><div dir="ltr"><div class="gmail_quote"><div></div><div>Ultimately I think the ideal approach is going to be abandoning CascadedUnion and switch to a full union algorithm (which will essentially be the same as running buffer(0).  This should have very good performance.  </div></div></div></blockquote><div><br></div><div> We're using PostGIS's ST_Union to dissolve a clipped TIN into a polygon. Current ST_Union implementation handles this measurably faster than ST_Buffer(ST_Collect(geom),0). Please keep this case in mind.</div></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail-m_9086141063943209617gmail-m_-3068001664160318967gmail_signature"><div dir="ltr"><div><div>Darafei Praliaskouski</div><div>Support me: <a href="http://patreon.com/komzpa" target="_blank">http://patreon.com/komzpa</a></div></div></div></div></div>
_______________________________________________<br>
geos-devel mailing list<br>
<a href="mailto:geos-devel@lists.osgeo.org" target="_blank">geos-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/geos-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/geos-devel</a></blockquote></div>
_______________________________________________<br>
geos-devel mailing list<br>
<a href="mailto:geos-devel@lists.osgeo.org" target="_blank">geos-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/geos-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/geos-devel</a></blockquote></div>