<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">In fixing <a href="https://trac.osgeo.org/postgis/ticket/5639">https://trac.osgeo.org/postgis/ticket/5639</a>, 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. <div><br></div><div>Right now, ST_DFullyWithin(A, B, radius) can be expressed as: </div><div> ST_MaxDistance(A, B) < radius<div><br></div><div>However, the distance <a href="https://postgis.net/docs/ST_MaxDistance.html">https://postgis.net/docs/ST_MaxDistance.html</a> 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.</div></div><div><br></div><div>Another way of expressing ST_DWithin(A, B, radius) is: </div><div> ST_Intersects(ST_Buffer(A, radius), B)</div><div><br></div><div>Another way of expressing what I *think* people expect from ST_DFullyWithin(A, B, radius) is: </div><div> ST_Contains(ST_Buffer(A), B)</div><div><br></div><div>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.</div><div><br></div><div>I propose changing ST_DFullyWithin to </div><div>(a) apply the buffer recipe</div><div>(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</div><div><br></div><div>The function will remain index-enabled, fortunately that logic still makes sense.</div><div><br></div><div>P</div></body></html>