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