Opened 6 months ago

Closed 6 months ago

# ST_DFullyWithin has unexpected semantics

Reported by: Owned by: pramsey pramsey medium PostGIS 3.5.0 postgis master

## Description

In fixing #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

• apply the buffer recipe
• 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.

### comment:1 by Paul Ramsey <pramsey@…>, 6 months ago

Resolution: → fixed new → closed

In f5d6c10/git:

Change behaviour of ST_DFullyWithin(A, B, R)
to be equivalent to ST_Contains(ST_Buffer(A, R), B).
This should more correctly match the behaviour users
expect and more logically extends on the behaviour
of ST_DWithin(A, B, R). Closes #5659.

Note: See TracTickets for help on using tickets.