Your understanding is correct, the approach is mostly brute force, and I have a pile of code lying about waiting to go in that implements what you describe in terms of building internal indexes.
P. On Tue, Apr 17, 2012 at 9:29 AM, Jose Carlos Martinez <jomar...@cgf.upv.es> wrote: > Thanks Sandro, I understand now. > > About trying to enhance ST_Dwithin, last time I checked PostGIS code it was > implemented using brute force (after comparing the boxes). Maybe one way to > improve the algorithm (DT_Dwithin) will be to use spatial indexes inside a > geometry. According to my tests (long time ago with JTS) I remember it could > be faster to build a spatial index every time for a geometry and use it than > using brute force (with geometries with more than 20 vertexes or so). > > Anyways Im not sure if PostGIS is still using brute force with st_dwithin, > if so then forget everything I said. > Regards, > > > On 17/04/2012 17:46, Sandro Santilli wrote: >> >> On Tue, Apr 17, 2012 at 05:35:42PM +0200, Jose Carlos Martinez wrote: >>> >>> Hi Sandro, Im learning from topology.sql how the topology functions >>> are working with more detail. >>> >>> I have a question about how the tolerances are managed, for example: >>> >>> I see (ST_AddIsoEdge) that you have used some times spatial >>> predicates as st_contains or st_intersects. As you know these >>> predicates (and others too) just work in a good way if the >>> geometries are snapped to each other previously, so my question is >>> why you didnt use st_Dwithin with a tolerance? or maybe these >>> functions expect the geometries to be already snapped by totopogeom >>> for example and they shouldnt be used directly? >> >> Those functions are ISO functions and as such are not specified to >> deal with a tolerance. Handling of tolerance is not always >> straightforward as using ST_DWithin. It may also have a big cost. >> >> So take all those functions as being expected to be already snapped. >> >> I'm open to suggestion about enhanced versions taking tolerance into >> consideration. But it must be possible to invoke such functions in >> a fast way, when caller already did their checking and noding and what >> not. >> >> The idea is that all the ST_ prefixed functions end up being just wrappers >> around more flexible functions in core. >> >> --strk; >> >> ,------o-. >> | __/ | Delivering high quality PostGIS 2.0 ! >> | / 2.0 | http://strk.keybit.net - http://vizzuality.com >> `-o------' >> >> _______________________________________________ >> postgis-users mailing list >> postgis-users@postgis.refractions.net >> http://postgis.refractions.net/mailman/listinfo/postgis-users > > > _______________________________________________ > postgis-users mailing list > postgis-users@postgis.refractions.net > http://postgis.refractions.net/mailman/listinfo/postgis-users _______________________________________________ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users