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

Reply via email to