ST_DFullyWithin

[Paul Ramsey]

> On Jan 25, 2024, at 10:19 AM, Bruce Rindahl <bruce.rindahl at gmail.com> wrote:
> 
> 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:

In general functions in SQL are less fun to upgrade. Will eventually do this via Hausdorf.

I don’t know that I agree about the parameter ordering, and I do not think the name of the function provides any guidance when I re-write it in object form, 

A.DFullyWithin(B,R)

at least not in the same way that

A.contains(B) 

makes parameter meaning clear.

It’s the “D” that wrecks it.

P

> 
> 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 <mailto: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/dc740c19/attachment.htm>