ST_DFullyWithin

[Paul Ramsey]

> On Jan 25, 2024, at 11:57 AM, Martin Davis <mtnclimb at gmail.com> wrote:
> 
> 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.

Concur, this is also my intuition, which is why it’s coded the way it is…

P

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20240125/f5400bcd/attachment.htm>