ST_DFullyWithin

Bruce Rindahl bruce.rindahl at gmail.com
Thu Jan 25 10:19:34 PST 2024


I agree with Regina.  Also why are we coding this as a function in C when
it can be done either of two ways in SQL:

ST_Contains(ST_Buffer(B, radius), A)
OR
ST_Within(A, ST_Buffer(B,radius))

For example there are numerous functions written in SQL that call the one
function ST_Affine.

On Thu, Jan 25, 2024 at 10:34 AM Regina Obe <lr at pcorp.us> wrote:

> > > > 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20240125/f184cd31/attachment-0001.htm>


More information about the postgis-devel mailing list