that is, i'm not saying GEOS should work in the way that i describe, i just mean it should know that it has a hit when one of the vertices intersects with the other polygon.<br>Probably i'm seeing things too simple, but i guess never asking is the best way to not get things improved, so i just ask stuff, even if it might be silly.<br>
<br><div class="gmail_quote">On Feb 19, 2008 10:14 AM, Willy-Bas Loos <<a href="mailto:willybas@gmail.com">willybas@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
yes, of course. I use this example just to illustrate the case.<br>What i really mean is: as soon as one of the veritices has a "hit", Intersects should return true and exit, no need to evaluate the rest (and Disjoint should return false).<br>
<br>As i come to think of how this might work: the one whole polygon should be evaluated against each veritice of the other. I guess that this means that the number of vertices that have to be parsed is equal to N(a) x N(b). But once you've detected that the first veritice in "a" intersects with polygon "b", youre done (or should be). <br>
I'm not sure if GEOS works this way (compare all 10000 vertices with all the other 10000 verices), but the difference in performance between the previous query and this next one, kind of suggests that is does. (added pointonsurface(a)).<div class="Ih2E3d">
<br>
<br> select 'yes' as foo<br>
from table1 a, table1 b<br>
where a.gid=4<br>
and b.gid=4<br></div>
and intersects(pointonsurface(a.the_geom), b.the_geom);<br>
<br>Maybe i should check the source code, even though i'm not a C programmer. Sry, my time is limited.<br><font color="#888888"><br>WBL</font><div><div></div><div class="Wj3C7c"><br>
<br><br><div class="gmail_quote">On Feb 19, 2008 1:54 AM, Paul Ramsey <<a href="mailto:pramsey@cleverelephant.ca" target="_blank">pramsey@cleverelephant.ca</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Right, this:<br><div><br> select 'yes' as foo<br> from table1 a, table1 b<br> where a.gid=4<br> and b.gid=4<br></div> and st_intersects(a.the_geom, b.the_geom)<br><br>seems likely to a LOT less common than<br>
<div><br> select 'yes' as foo<br> from table1 a, table1 b<br> where a.gid=4<br></div> and st_intersects(a.the_geom, b.the_geom)<br><br>and the latter gets far less benefit from the a.getpoint(0) =<br>
b.getpoint(0) test, though the test would still be run on every<br>candidate. I'm not sure where the cost/benefit inflection point is,<br>but I know identity is a pretty rare case.<br><font color="#888888"><br>P.<br>
</font><div><div></div><div><br>On 2/18/08, Martin Davis <<a href="mailto:mbdavis@refractions.net" target="_blank">mbdavis@refractions.net</a>> wrote:<br>> There's some new code on the way in GEOS and PostGIS which will improve<br>
> the performance of this case. Bu it won't be anywhere near as fast as<br>> your proposed check for an identical start point.<br>><br>> The "identical start point" check is great for the particular case of<br>
> comparing identical polygons. But it does nothing for the general<br>> case. The question is: is the identical compare case common enough<br>> that it's worth adding in this check for all cases?<br>><br>
> Willy-Bas Loos wrote:<br>> > Hi,<br>> ><br>> > I´ve noticed that intersect(a,b) is slow when i compare a (nice and<br>> > large) geometry with itself.<br>> > so the syntax is:<br>> ><br>
> > select 'yes' as foo<br>> > from table1 a, table1 b<br>> > where a.gid=4<br>> > and b.gid=4<br>> > and intersects(a.the_geom, b.the_geom)<br>> ><br>> > This particular polygon has about 10 000 points, and the query runs<br>
> > for 4 whole seconds.<br>> > At the first point that is being compared, however, PostGIS should<br>> > notice that it has a "positive".<br>> ><br>> > I´m only using postgis 1.0, so this migt have been changed allready.<br>
> > Has it?<br>> ><br>> > WBL<br>> ><br>> > ------------------------------------------------------------------------<br>> ><br>> > _______________________________________________<br>
> > postgis-users mailing list<br>> > <a href="mailto:postgis-users@postgis.refractions.net" target="_blank">postgis-users@postgis.refractions.net</a><br>> > <a href="http://postgis.refractions.net/mailman/listinfo/postgis-users" target="_blank">http://postgis.refractions.net/mailman/listinfo/postgis-users</a><br>
> ><br>><br>> --<br>> Martin Davis<br>> Senior Technical Architect<br>> Refractions Research, Inc.<br>> (250) 383-3022<br>><br>> _______________________________________________<br>> postgis-users mailing list<br>
> <a href="mailto:postgis-users@postgis.refractions.net" target="_blank">postgis-users@postgis.refractions.net</a><br>> <a href="http://postgis.refractions.net/mailman/listinfo/postgis-users" target="_blank">http://postgis.refractions.net/mailman/listinfo/postgis-users</a><br>
><br>_______________________________________________<br>postgis-users mailing list<br><a href="mailto:postgis-users@postgis.refractions.net" target="_blank">postgis-users@postgis.refractions.net</a><br><a href="http://postgis.refractions.net/mailman/listinfo/postgis-users" target="_blank">http://postgis.refractions.net/mailman/listinfo/postgis-users</a><br>
</div></div></blockquote></div><br>
</div></div></blockquote></div><br>