<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><br><div><br><blockquote type="cite"><div>On Jan 25, 2024, at 10:19 AM, Bruce Rindahl <bruce.rindahl@gmail.com> wrote:</div><br class="Apple-interchange-newline"><div><div dir="ltr">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:</div></div></blockquote><div><br></div><div>In general functions in SQL are less fun to upgrade. Will eventually do this via Hausdorf.</div><div><br></div><div>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, </div><div><br></div><div>A.DFullyWithin(B,R)</div><div><br></div><div>at least not in the same way that</div><div><br></div><div>A.contains(B) </div><div><br></div><div>makes parameter meaning clear.</div><div><br></div><div>It’s the “D” that wrecks it.</div><div><br></div><div>P</div><br><blockquote type="cite"><div><div dir="ltr"><div><br></div><div>ST_Contains(ST_Buffer(B, radius), A)<br>OR<br>ST_Within(A, ST_Buffer(B,radius))<br></div><div><br></div><div>For example there are numerous functions written in SQL that call the one function ST_Affine.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 25, 2024 at 10:34 AM Regina Obe <<a href="mailto:lr@pcorp.us">lr@pcorp.us</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> > > Another way of expressing ST_DWithin(A, B, radius) is:<br>
> > > ST_Intersects(ST_Buffer(A, radius), B)<br>
> > ><br>
> > > Another way of expressing what I *think* people expect from<br>
> > ST_DFullyWithin(A, B, radius) is:<br>
> > > ST_Contains(ST_Buffer(A), B)<br>
> > ><br>
> > > The canonical use case of something like ST_DFullyWithin(A, B,<br>
> > > radius) would<br>
> > be checking to see if two line segments were “similar”, so a road<br>
> > conflation problem. The current implementation will very much not help with<br>
> that.<br>
> > ><br>
> > > I propose changing ST_DFullyWithin to<br>
> > > (a) apply the buffer recipe<br>
> > > (b) once a new version of GEOS with an oriented hausdorf is<br>
> > > available, use that<br>
> > implementation instead to calculate the distance metric the buffer<br>
> > recipe implies<br>
> > ><br>
> > > The function will remain index-enabled, fortunately that logic still makes<br>
> sense.<br>
> > ><br>
> > > P<br>
> I agree with the change.<br>
<br>
Please don't kill me for rethinking this, but I think ST_DFullyWithin(A,B, radius)<br>
<br>
Should be <br>
<br>
ST_Contains(ST_Buffer(B, radius), A)<br>
<br>
The reason being, is to be consistent with our non-symmetric functions like <br>
<br>
ST_Within(A,B) we read that as A is within B or corollary B contains A<br>
<br>
So to me I think people expect:<br>
<br>
ST_DFullyWithin(A,B, radius) to mean A is fully within the radius of B thus<br>
<br>
ST_Contains(ST_Buffer(B, radius), A)<br>
<br>
OR<br>
<br>
ST_Within(A, ST_Buffer(B,radius))<br>
<br>
Remember I'm direction challenged, so I could be completely wrong.<br>
<br>
</blockquote></div>
</div></blockquote></div><br></body></html>