ST_DFullyWithin

Regina Obe lr at pcorp.us
Thu Jan 25 12:02:26 PST 2024


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 <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/120535be/attachment.htm>


More information about the postgis-devel mailing list