On Tue, Apr 17, 2012 at 09:58:01AM -0700, Paul Ramsey wrote: > On Apr 17, 2012 Jose Carlos Martinez <jomar...@cgf.upv.es> wrote: > > On 17/04/2012 17:46, Sandro Santilli wrote: > >> > >> 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. > > > > 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 > > 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.
But still my observation about cost wasn't specific to ST_DWithin. The thing is I'm not sure you can use ST_DWithin for everything. An interesting case could be the one of adding a pie cut in 16 slices. There would be a central node from which 16 edges depart. Distance between each edge and the other would be close to 0, but the edges would really only touch at the endpoint. Any tolerance other than zero would prevent adding more than a single edge. Actually, now that I imagine that case I'm not sure ST_Snap would be doing the right thing in that case. Probably not. Until it's modified to always snap to the _closest_ point. --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