ST_DFullyWithin

Regina Obe lr at pcorp.us
Thu Jan 25 09:29:03 PST 2024


> > > Another way of expressing ST_DWithin(A, B, radius) is:
> > >   ST_Intersects(ST_Buffer(A, radius), B)
> > >
> > > Another way of expressing what I *think* people expect from
> > ST_DFullyWithin(A, B, radius) is:
> > >   ST_Contains(ST_Buffer(A), B)
> > >
> > > The canonical use case of something like ST_DFullyWithin(A, B,
> > > radius) would
> > be checking to see if two line segments were “similar”, so a road
> > conflation problem.  The current implementation will very much not help with
> that.
> > >
> > > I propose changing ST_DFullyWithin to
> > > (a) apply the buffer recipe
> > > (b) once a new version of GEOS with an oriented hausdorf is
> > > available, use that
> > implementation instead to calculate the distance metric the buffer
> > recipe implies
> > >
> > > The function will remain index-enabled, fortunately that logic still makes
> sense.
> > >
> > > P
> I agree with the change.

Please don't kill me for rethinking this, but I think ST_DFullyWithin(A,B, radius)

Should be 

ST_Contains(ST_Buffer(B, radius), A)

The reason being, is to be consistent with our non-symmetric functions like 

ST_Within(A,B)  we read that as A is within B or corollary B contains A

So to me I think people expect:

ST_DFullyWithin(A,B, radius)  to mean A is fully within the radius of B thus

ST_Contains(ST_Buffer(B, radius), A)

OR

ST_Within(A, ST_Buffer(B,radius))

Remember I'm direction challenged, so I could be completely wrong.



More information about the postgis-devel mailing list