ST_DFullyWithin

[Paul Ramsey]

Already doc’ed and theres a NEWS entry in the Breaking change section.
P

> On Jan 25, 2024, at 12:02 PM, Regina Obe <lr at pcorp.us> wrote:
> 
> Ah yes I was thinking about that that we should be using ST_Covers.  Good catch.
>  I’m fine with either way as long as the description is updated in the docs, and it’s clearified that this is a breaking change.  I doubt that many people used this function so I don’t think too many will be impacted, but it is a change in behavior and should be clearly stated as such.
> That said, it can’t be backported.
>  From: Martin Davis <mtnclimb at gmail.com> 
> Sent: Thursday, January 25, 2024 2:57 PM
> Cc: PostGIS Development Discussion <postgis-devel at lists.osgeo.org>
> Subject: Re: ST_DFullyWithin
>  Another reason for keeping the meaning "ST_DFullyWithin(A, B) = ST_Covers(ST_Buffer(A, Dist), B)":
>  I see the main use of this function in queries to be "find all the B features which are fully within distance D of an A feature".  So the A feature is the *constant* "query item", and it is evaluated against a set of B features.  It seems more intuitive for the constant feature to be the first argument in functions.
>  PS note the definition needs to use Covers rather than Contains, due to that ol' quirky definition of Contains! 
>  On Thu, Jan 25, 2024 at 10:57 AM Paul Ramsey <pramsey at cleverelephant.ca> wrote:
>> 
>> 
>>  
>> 
>>> 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.