[geos-devel] CoverageUnion

[Paul Ramsey]

On Tue, Apr 18, 2023 at 5:24 PM Daniel Baston <dbaston at gmail.com> wrote:
>
>  I think it would be a good idea to apply an area post-check to the NG version so that we retain the error.

We have not been able to conjure up a way to note non-coverage inputs
without incurring a huge performance penalty. The NG coverage union
does not return empty on non-valid inputs, it frequently just mirrors
the non-valid parts back on the output. An area test won't catch those
cases necessarily, since the area of the input will equal the area of
the output for example if you feed in two polygons with an overlap and
no shared edges. I am tempted to change the contract and document that
a validity check is a precondition for getting "sensible" results on
output.

> 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.

I have added the sorting, and have not yet found a case where the NG
version is slower. Also I have found that doing a union on my 5000
voting area test set, the algorithms are close in speed when
aggregating to one big output, but slower when aggregating 80 smaller
outputs. There must be a somewhat larger fixed cost per calculation in
the operation/union version than the NG one.

(for clarity, this is similar for both implementations, just one output)

  SELECT ST_CoverageUnion(geom) FROM vas;

(and this is 10x slower on the operation/union implementation, 85 outputs)

  SELECT edavbbr ST_CoverageUnion(geom) FROM vas GROUP BY edabbr;

Anyways, question for going forward: OK to change the contract on
GEOSCoverageUnion?

P

>
> Otherwise I have no reservations about switching.
>
> Dan
>
> On Tue, Apr 18, 2023 at 7:05 PM Martin Davis <mtnclimb at 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 <pramsey at 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 at lists.osgeo.org
>>> https://lists.osgeo.org/mailman/listinfo/geos-devel
>>
>> _______________________________________________
>> geos-devel mailing list
>> geos-devel at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/geos-devel
>
> _______________________________________________
> geos-devel mailing list
> geos-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel