[geos-devel] Possible speed improvement for overlay operations

[Martin Davis]

Thanks for the test data.  In my Java environment intersection computes in
3.8 s  :)    That is definitely one of the gnarlier polygon geometries I've
seen - even worse than muskeg lakes :)

Also, the covers predicate computes in 1.3 s, so adding that test into the
path would definitely be beneficial - for this particular case.  This is
pretty data-specific, though - it depends how many cases in the overall
computation allow short-circuiting via that test.  Did you try the PostGIS
query using the combination of predicates and intersection?

So maybe a pre-evaluation covers check is best left as an option to the
Overlay code, so that intermediate structures can be reused.  In other
words, provide an optional flag on the Overlay operation which does a
covers check before computing the full result, utilizing the internal
segment indexing to perform the check quickly.

And as you say, if this can be prepared it should make an even bigger
difference.  This requires knowing which side of the operation is the one
that should be prepared - is this obvious in your data context?

On Tue, Dec 4, 2018 at 1:10 PM Paul van der Linden <
paul.doskabouter at gmail.com> wrote:

> It's in the overlay ops.
> Still impressive that this can be done in just over 10 seconds, and I'm
> sure prepared geometries will help even more!
> Also surprising is that for that st_intersection to run in debug-mode in
> visual studio it never finished within my patience window, and that if run
> from postgres it takes about 50-60 seconds...
>
> _______________________________________________
> geos-devel mailing list
> geos-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geos-devel/attachments/20181204/712339f4/attachment.html>