<div dir="ltr"><div><div><div><div><div><div><div>Hey,<br></div>I highjack this interesting discussion, sorry =)<br><br></div>If you have one single massive Polygon (no multi).<br></div>You can generate a point table (keeping path of course) with ST_DumpPoints.<br><br></div>Then you construct an index on this table.<br></div>Then you perform your Intersection with indexed points, which will be very fast.<br></div><div>Then you reconstruct parts of polygon.<br></div><div>It will require some advanced to very advanced SQL (like windows function) to make it work tough.<br><br></div><div>I think it would be faster than other alternatives, because basicaly it amounts to using the optimized R-Tree index on points, vs a custom and non-otpimized Quad tree index on polygon.<br></div><div>Moreover when using a recusrive strategy, you end up computing the same think a lot with geos.<br><br></div>Cheers,<br></div>Rémi-C<br></div><div class="gmail_extra"><br><div class="gmail_quote">2015-02-24 23:10 GMT+01:00 Mark Wynter <span dir="ltr"><<a href="mailto:mark@dimensionaledge.com" target="_blank">mark@dimensionaledge.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> Thanks Mark.  I will indeed do the st_dump, but I don't think it will help much (very few multis).  I think the tiling will help a lot.  What I wonder, though, is how long it will take to tile?  Afterall, it's still an st_intersection operation to tile each geometry against each tile.<br>
<br>
I’ve almost finished writing the tutorial - where I address many of these points.    The variables that affect performance are:<br>
* how you’ve written your ST_Intersection query<br>
* multi vs. non-multi<br>
* size and complexity of geoms<br>
* no. available CPUs (for parallelisation)<br>
* tile batch size - important!!!<br>
<br>
All strategies in combination may be necessary if your queries are taking forever.<br>
<br>
For the demonstration dataset (a multi polygon representing whole of Australia), my tutorial tiling query incorporates ST_Intersection and ST_Difference subqueries to produce tiled features representing land and water.<br>
I achieved a 49x reduction in the query time to tile the whole of Australia, starting with a single multi polygon.<br>
<br>
The more complex the query, the more significant this time saving is in absolute terms.<br>
<br>
> Is there a quad tree type tiling algorithm in a function?  If I do 256 x 256 tiles, doing it all at once would be 65536 operations of st_intersection(complex_geom, square).  With a quad tree I'll only have 4 operations of st_intersection(complex_geom, square), and then 16 of (a_little_less_complex_geom, square), and then 64 of (even_less_complex_geom, square) and so on, for 8 nests.  The last one will still be 65536 operations, but the complex geoms should be a lot simpler by the time I get down to that level.  What do you think, is this worth trying?  Or is intersecting with a square fairly simple regardless of how complex the other geometry is?<br>
<br>
I do have a SQL quadgrid tiling function - where a cell divides recursively subject to a maximum number of levels or “value thresholds” - but I’m not sure if that’s the right approach.<br>
_______________________________________________<br>
postgis-users mailing list<br>
<a href="mailto:postgis-users@lists.osgeo.org">postgis-users@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users" target="_blank">http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users</a><br>
</blockquote></div><br></div>