[postgis/postgis] Implement ST_Distance via GEOS (#218)

[Paul Ramsey]

> On Sep 26, 2024, at 10:05 AM, Sandro Santilli <strk at kbt.io> wrote:
> 
> On Thu, Sep 26, 2024 at 12:57:02PM -0400, Regina Obe wrote:
>>>> On Sep 26, 2024, at 9:49 AM, Regina Obe <lr at pcorp.us> wrote:
>>>> 
>>>> Would there be any benefit to exposing it under a different name like
>>> _ST_DistanceGeos so for cases like what strk mentioned, it could be used and
>>> also so we can more easily compare the penalty in use.
>>> 
>>> Well, we can do that in a PR, and strk’s PR here just does the same idea only by
>>> retaining a ST_Distance_LWGeom, so he can performance test his branch.
>>> 
>>>> I recall reading somewhere that in PostgreSQL 17 they improved some of
>>> the copy logic.  I could be completely imagining that though.
>>>> Remember we just started the PostGIS 3.6 cycle, so now is the time to be a
>>> bit adventurous.
>>> 
>>> We do have lots of time to fix things! Fixing the precision issues would be
>>> back-portable though, while changing the implementation to a GEOS back-
>>> end, probably not.
>>> 
>> Okay if it's simpler to fix the local distance calc then yah we should do that.  I just wasn't sure which approach was easier.
>> Agree the GEOS backend would not be backportable at least the way I'm envisioning it.
>> I also don't know if GEOS has changed dist calcs over the years that such as change may raise more questions than solve problems.
> 
> My main problem about this is that I dont KNOW which answer is the
> correct one.

Martin and I were discussing over coffee and the idea of using the DD math in GEOS to get a “most correct” answer came up. We could then evaluate the implementations for this test case against that number.

> Looking at the GEOS implementation it looks like GEOS
> finds the closest point on the segment and the computes the distance
> from it, while PostGIS does not do the construction. This would make
> me think that PostGIS implementation is more correct, but how to tell
> when you can't trust your eyes ? :(
> 
> If we could give different names to the different algorithms we could
> expose distinct functions, yes. Only problem is that I'm using:
> 
>   ORDER BY <-> LIMIT 1
> 
> And you cannot specify an algorithm there, for the recheck function, unless
> we resort to GUC that I know you guys hate ? Is there any other way to
> hook on the ORDER BY <-> with some custom recheck functions ?

Well, you can redefine the operator, so for testing purposes… but to make a user-“friendly” run-time knob? Yeah, that seems Hard. I’m not super +1 on having all these implementations separately exposed, but that’s an aesthetic thing primarily. 

P.

> 
> --strk;

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