ST_DFullyWithin

[Regina Obe]

> On Wed, Jan 24, 2024 at 12:53 PM Paul Ramsey <pramsey at cleverelephant.ca>
> wrote:
> >
> > In fixing https://trac.osgeo.org/postgis/ticket/5639, it has become clear to me
> that our definition of ST_DFullyWithin is probably “wrong”, that is, it’s not what
> people think they are getting when they call it.
> >
> > Right now, ST_DFullyWithin(A, B, radius) can be expressed as:
> >   ST_MaxDistance(A, B) < radius
> >
> > However, the distance https://postgis.net/docs/ST_MaxDistance.html returns
> is the maximum distance between the vertices of A and the vertices of B. In the
> limit, for example, the ST_MaxDistance(A, A) is not zero, it’s the longest distance
> between any two vertices of A. This is fine, there’s a place for this number, but
> applied to ST_DFullyWithin, it doesn’t return what I think people expect.
> >
> > 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.