I noticed that the OverlayNG coverage union returns an empty polygon if the inputs do not form a coverage, whereas the older algorithm produces an error. I think it would be a good idea to apply an area post-check to the NG version so that we retain the error. I have also noticed cases (TIGER county boundaries) where the NG algorithm takes about 2x as long as the old algorithm but performs better than the old algorithm if the inputs are pre-sorted (as they are in the old algorithm). Maybe the same sorting should be added to the NG version.
Otherwise I have no reservations about switching. Dan On Tue, Apr 18, 2023 at 7:05 PM Martin Davis <mtncl...@gmail.com> wrote: > geos/coverage/CoverageUnion in fact delegates to > geos/operation/overlayng/CoverageUnion. It's there to provide an API which > is the same as the other coverage operations. > > overlayng/CoverageUnion seems to be quite a bit faster than > geos/operation/union/CoverageUnion, by my testing. So it has my vote.(They > are both exposed in geosop, so independent verification is welcome.) > > On Tue, Apr 18, 2023 at 3:56 PM Paul Ramsey <pram...@cleverelephant.ca> > wrote: > >> We have quite a few of them? Which one should be keep and bind into CAPI? >> >> geos/operation/union/CoverageUnion.h >> geos/operation/overlayng/CoverageUnion.h >> geos/coverage/CoverageUnion.h >> _______________________________________________ >> geos-devel mailing list >> geos-devel@lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/geos-devel >> > _______________________________________________ > geos-devel mailing list > geos-devel@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/geos-devel >
_______________________________________________ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
