I put it in. I'm going to flip over to the ng coverage union for CAPI,
with the area test in place now.
On Sat, Apr 29, 2023 at 5:15 PM Daniel Baston wrote:
>>
>> We have not been able to conjure up a way to note non-coverage inputs
>> without incurring a huge performance penalty.
>
>
> I think t
I request you to please unsubscribe my mail from this updates.
-Chirag
On Sunday, April 30, 2023 at 05:45:19 AM GMT+5:30, Daniel Baston
wrote:
We have not been able to conjure up a way to note non-coverage inputs
without incurring a huge performance penalty.
I think the area tes
> We have not been able to conjure up a way to note non-coverage inputs
> without incurring a huge performance penalty.
I think the area test we have been using catches many non-contrived cases
with essentially no penalty. What is the benefit to removing it?
Dan
_
The definition of a valid Simple Polygonal Coverage is presented here:
http://lin-ear-th-inking.blogspot.com/2022/08/validating-polygonal-coverages-in-jts.html
It's in the JTS Javadoc here:
https://github.com/locationtech/jts/blob/master/modules/core/src/main/java/org/locationtech/jts/coverage/C
On Wed, Apr 26, 2023 at 12:45:41PM -0700, Paul Ramsey wrote:
> I am tempted to change the contract and document that
> a validity check is a precondition for getting "sensible" results on
> output.
Where's the contract ? I was curious to understand what would
ST_CoverageUnion do for me but only f
On Tue, Apr 18, 2023 at 5:24 PM Daniel Baston 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 covera
On Tue, Apr 18, 2023 at 5:24 PM Daniel Baston wrote:
> 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.
>
The first step in the union algorithm is to identify segments which
On Tue, Apr 18, 2023 at 5:24 PM Daniel Baston wrote:
> 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 t
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
count
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 vo
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.osg
11 matches
Mail list logo
