<div dir="ltr"><div>My PostGIS implementation may be lost to time, but I can put together a GEOS implementation during or maybe before the sprint.</div><div><br></div>Yes, if exposed in PostGIS it would have to be as a separate function. One correctness check is that area is preserved; it's difficult for me to imagine a case where the algorithm I described produces an incorrect result that still preserves area, but perhaps it's possible.<div><br></div><div>I used it most often for unioning subsets of triangulations or Voronoi diagrams, but it did produce correct results on every TIGER dataset I tried. It is tolerant of some noding errors, as long as they're not on a boundary of the dissolved polygon.</div><div><br></div><div>Dan</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 16, 2019 at 11:38 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">I've also been thinking that for the case of unioning a polygonal coverage there could be a much faster algorithm.  Good to hear that you have an implementation lined up.  Can you work up a GEOS version based on your Java code?  (And if there are any extension needed to the Polygonizer to support it, those can be in scope as well).<div><br></div><div>Are you thinking this would be exposed as a different PostGIS function (say ST_UnionCoverage)?  </div><div><br></div><div>I'm aconcerned about what happens if the input is not a valid polygonal coverage.  It can be very hard to "see" if a dataset is coverage-valid.  (For instance, the dataset of Norwegian poiygons that was posted recently is *almost* a valid coverage, but out of it's 1.2 M segments has about 3 which cross slightly!  It might be important to provide a IsCoverageValid function, or perhaps even better a function to report the locations of crossing segments.  And ideally the ST_UnionCoverage function could report an error on invalid input - but it's not clear how to do that efficiently, which would defeat the purpose.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 16, 2019 at 8:21 AM Daniel Baston <<a href="mailto:dbaston@gmail.com" target="_blank">dbaston@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">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" target="_blank">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" target="_blank">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" 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">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_1774493233941134087gmail-m_489441436665980551gmail-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>
_______________________________________________<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>