<div dir="ltr"><div><div><div><div>Hey,<br><br></div>it is conceptually possible to accelerate a query on a single row content (aka one big geometry).<br></div>The probleme is that it is no more a database index (which is a way to find a row very quick, but in this case we __already__ know the row).<br>
</div><div>It is a bit like the raster storage and the JPEG 2000 standard with embedded pyramidal view<br></div><div><br></div><div>You could implement something similar, but there is no clear equivalent to this pyramidal simplification for vector (for instance, you may want a pyramid of simpler and simpler geometries (1000 points in contour, then 100 points, then 10 points), or a pyramid where a surface becomes a point at a given level, etc). You would have all sort of topological problem.<br>
</div><div>This whole "how do I simplify a vector" is a very actively researched area (and no fully automatic solution found yet )<br></div><div><br></div>Postgres index system could probably be hijacked because you can index the result of any function, but it would be a bad idea.<br>
<br></div><div>As a side not<br>_ in your first use case, you could have forced the use of index by adding to the intersect :<br></div><div>AND admin.geom && other.geom,<br></div><div>or even computing this as a first step.<br>
</div>_your admlinistrativ limit seems to be a partition of the space (no overlaping). In this case there exist very fast way to get the intersect answer, but it is not used in GIS field. <br><br><br><div>Cheers,<br>Rémi-C<br>
<div><div><div><div><br></div></div></div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-05-21 15:12 GMT+02:00 Alexander Korotkov <span dir="ltr"><<a href="mailto:aekorotkov@gmail.com" target="_blank">aekorotkov@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="">On Wed, May 21, 2014 at 1:02 PM, Jeremy Palmer <span dir="ltr"><<a href="mailto:JPalmer@linz.govt.nz" target="_blank">JPalmer@linz.govt.nz</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">





<div link="blue" vlink="purple" lang="EN-NZ">
<div>
<p class="MsoNormal">Hi PostGIS Devs,<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">I have a daily process that I would like to optimise. The process includes a spatial intersects join between a small administration boundaries table for New Zealand that contains large geometries (100,000+ points per polygon) and a large
 dataset with small line strings.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">The first iteration of SQL I developed for the process I used standard join (WHERE ST_Interesects(admin.geom, other.geom)) and it took 4 hours to complete. No spatial index was used. Not acceptable.</p>


</div></div></blockquote><div><br></div></div><div>So, your task is so-called "spatial join". We are now doing researches on it. It would be nice if you could share your dataset so we can do experiments on it. <br>
</div>

<div><br></div>------<br>With best regards,<br>Alexander Korotkov.</div><br></div></div>
<br>_______________________________________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org">postgis-devel@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel" target="_blank">http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel</a><br></blockquote></div><br></div>