[PostGIS] #5659: ST_DFullyWithin has unexpected semantics

PostGIS trac at osgeo.org
Thu Jan 25 08:03:38 PST 2024


#5659: ST_DFullyWithin has unexpected semantics
---------------------+---------------------------
 Reporter:  pramsey  |      Owner:  pramsey
     Type:  defect   |     Status:  new
 Priority:  medium   |  Milestone:  PostGIS 3.5.0
Component:  postgis  |    Version:  master
 Keywords:           |
---------------------+---------------------------
 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.
-- 
Ticket URL: <https://trac.osgeo.org/postgis/ticket/5659>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.


More information about the postgis-tickets mailing list