<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Dec 5, 2018 at 10:02 AM Paul van der Linden <<a href="mailto:paul.doskabouter@gmail.com" target="_blank">paul.doskabouter@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div style="font-size:small">> Thanks for the test data.  In my Java environment intersection computes in<br>> 3.8 s  :)    That is definitely one of the gnarlier polygon geometries I've<br>> seen - even worse than muskeg lakes :)<br>> </div><div style="font-size:small"><br></div><div style="font-size:small">Wow 3.8 sec is that the old version or the one with the envelope check?</div><div style="font-size:small"><br></div></div></div></div></blockquote><div>Yes.  It turned out that JTS already had the envelope check in place (at least for polygon rings - I just added a check at the top-level too, but it doesn't make any difference, since there are only a few polygons in this case.) </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div style="font-size:small"></div><div style="font-size:small"><br></div><div style="font-size:small">
<div style="font-size:small">> Also, the covers predicate computes in 1.3 s, so adding that test into the<br>> path would definitely be beneficial - for this particular case.  This is<br>> pretty data-specific, though - it depends how many cases in the overall<br>> computation allow short-circuiting via that test.  Did you try the PostGIS<br>> query using the combination of predicates and intersection?<br>></div><div style="font-size:small"><br></div><div style="font-size:small">Certainly wouldn't add that if it takes about 30% of the time, and I'm not sure if I have the full picture of all the edgecases</div><div style="font-size:small">Did try quite some combinations of predicate and intersections. predicares took about 40s, intersection about 60<br></div></div></div></div></div></blockquote><div><br></div><div>Fair enough, if adding predicates doesn't improve the overall computation time. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div style="font-size:small"><div style="font-size:small"></div><div style="font-size:small"><br></div><div style="font-size:small">In the mean time, I learnt from the code that in case of overlap there will be expensive computations done, so I rewrote (actually: planning to :) ) my queries from st_intersection(geo,"world-country") to st_difference(geo,"country"). As the "county" is much smaller, a lot of stuff can be calculated just based on envelope.<br></div></div></div></div></div></blockquote><div><br></div><div>Hmmm - is this because st_difference includes an envelope check?  In PostGIS or GEOS?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div style="font-size:small"><div style="font-size:small"></div><div style="font-size:small">Did a test, and one of the queries that took over 30 hours was now done in 18 hours, so that's quite an improvement. Only drawback is that having some queries with a st_difference and some with st_intersection isn't helping in the clarity of the whole workflow... Added benefit is that with the st_difference, I don't get line and point geometries that are on the boundary<br></div></div></div></div></div></blockquote><div><br></div><div>Returning lines and points from area intersections is a design decision made in the very first release of JTS.  I always wonder if that was the best decision, or whether the default should have been to return only geometry of the largest dimension, and provide another method if all are required.  Seems like it would be useful to add such a function to PostGIS, at least.  (Actually would be nice to be able to specify which dimension(s) were of interest, to support all use cases.).</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div style="font-size:small"><div style="font-size:small"></div><div style="font-size:small"><br></div><div style="font-size:small">What would help in this case is probably an idea I posted here: <a href="https://lists.osgeo.org/pipermail/postgis-users/2018-December/043029.html" target="_blank">https://lists.osgeo.org/pipermail/postgis-users/2018-December/043029.html</a></div></div></div></div></div></blockquote><div><br></div><div>I am following that thread.   I'm hoping that it would be possible to implement a smarter, caching ST_IntersectionPrepared (or some such name) which would allow this very simple query:</div><div><br></div><div><div>select ST_IntersectionPrepared(geomA, geomB) R </div><div>from A join B on A.geom && B.geom</div><div>where R != empty/null</div></div><div><br></div><div>This would include the contains check internally, for maximum performance and reuse of intermediate results.</div><div><br></div></div></div>