# [postgis-users] points from st_distance

Obe, Regina robe.dnd at cityofboston.gov
Thu Feb 12 08:13:42 PST 2009

``` Steve,
Oops  I meant to say that I think PostGIS implements its own algorithm
for distance.  GEOS does have a distance calculation, and I'm actually
kind of curious why that one is not used or maybe it was just more
efficient speedwise to implement in PostGIS directly.

-----Original Message-----
From: Obe, Regina
Sent: Thursday, February 12, 2009 11:07 AM
To: 'PostGIS Users Discussion'
Subject: RE: [postgis-users] points from st_distance

Well distance actually is not implemented in GEOS.  PostGIS uses its own
algorithm for that as I recall.

-----Original Message-----
From: postgis-users-bounces at postgis.refractions.net
[mailto:postgis-users-bounces at postgis.refractions.net] On Behalf Of
Stephen Woodbridge
Sent: Thursday, February 12, 2009 10:54 AM
To: PostGIS Users Discussion
Subject: Re: [postgis-users] points from st_distance

Ok, that would be cool. I could see a function like
ST_ShortestLineBetween(geometry, geometry) that would return a line.

You might want to write an enhancement bug for that. Since these things
are implemented in GEOS, you might also want to add the request to the
GEOS tracker too.

-Steve.

nicklas.aven at jordogskog.no wrote:
>
> Thanks a lot
>
> Regina is right about what I want to do and I agree that "any of the
> points that satisfies the below
> condition is a solution to that"
>
> I made some corresponding solution in avenue a few years ago but
without
> buffer.
>
> I don't think there is a practical problem, if you know about it, if
you
> just get one of possible many points at the same shortest distance.
> If the geometries is not snapped to a grid there should be very few
> cases when more than one point from each geometry represents the
> shortest line between the geometries if the precision of the
> calculations is good enough.
> I still think it would be great with a built in function. I think it
> ought to be much more efficient to get the points at the same time as
> finding the closest distance instead of throwing them away inside the
> function and then finding them again outside the function.
>
> This is not an acute problem for me right now but I can see a lot of
> possibilites from such a function. It would be possible to easy build
> snapfunctions. It would also increase the possibilites to analyze
what's
> between two geometries.
>
> If we could get the shortest line between geometries just as effective

> as we now get the shortest distance I think it would open many doors.
> Back in avenue this problem blocked the creative developing thinking
> many times. But that's just from my quite amateur point of view.
>
> thanks again
> Nicklas
>
> 2009-02-11 Paragon Corporation wrote:
>
> Steve,
>  >
>  >Maybe I misunderstood his question. I thought what he was asking was
>  >
>  >1) since ST_Distance gives the distance between the 2 points of each
>  >geometry that are closest. What is that point(s) that it is using.
>  >
>  >So our thinking is is that any of the points that satisfies the
below
>  >condition is a solution to that
>  >
>  >So say you have Geometry A and geometry B and you want to know what
set of
>  >points on Geometry A are closest to Geometry B
>  >
>  >The answer would be
>  >
>  >SELECT ST_Intersection(A, ST_Buffer(B, ST_Distance(A,B)))
>  >
>  >Hope that helps,
>  >Regina
>  >
>  >-----Original Message-----
>  >From: postgis-users-bounces at postgis.refractions.net
>  >[mailto:postgis-users-bounces at postgis.refractions.net] On Behalf Of
> Stephen
>  >Woodbridge
>  >Sent: Wednesday, February 11, 2009 11:50 AM
>  >To: PostGIS Users Discussion
>  >Subject: Re: [postgis-users] points from st_distance
>  >
>  >Hmmmm, why not do something like:
>  >
>  >
>  >select *, ST_distance(point, object) as dist from table
expand(point,
>  >min_distance) && object and dist <= min_distance order by dist limit
1;
>  >
>  >-Steve
>  >
>  >
>  >Paragon Corporation wrote:
>  >>
>  >> Nicklas,
>  >>
>  >> You are correct there is no function for doing this. We have on
>  >> occasion needed to do this ourselves and what we usually do is
>  >>
>  >> 1) first find the minimum distance
>  >> 2) figure out which point/pointset on the geometry satisfies the
>  >> minimum distance using buffer and intersection (with minimum
distance
>  >> being the buffer distance).
>  >>
>  >> I think I have the code lying around here somewhere.
>  >>
>  >> As far as ST_Distance goes. Haven't looked at the code that
closely,
>  >> but it does some sort of recursive call and there could be more
than
>  >> one point that satisfies the condition and it only cares about the
>  >> first one it comes across so such a thing may or may not be quite
what
>  >> you are looking for.
>  >>
>  >> Hope that helps,
>  >> Regina
>  >>
>  >>
>  >>
>  >> *From:* postgis-users-bounces at postgis.refractions.net
>  >> [mailto:postgis-users-bounces at postgis.refractions.net] *On Behalf
Of
>  >> *nicklas.aven at jordogskog.no
>  >> *Sent:* Wednesday, February 11, 2009 4:47 AM
>  >> *To:* postgis-users at postgis.refractions.net
>  >> *Subject:* [postgis-users] points from st_distance
>  >>
>  >> Hallo
>  >>
>  >> I have a question or suggestion.
>  >>
>  >> If I have missed some functionality please tell me.
>  >>
>  >> The thing is I have often needed information about from which
points
>  >> the distance in st_distance is calculated.
>  >> I mean, somewhere in the function the information have to be.
Would it
>  >> be possible to build a new function which returned the distance,
>  >> startpoint, endpoint as array or something like that.
>  >>
>  >> Am I right about that this functionality is missing and am I right
>  >> about that the points have to be identified somewhere in the
function
>  >> and that it ought to be possible to present them in a function.
>  >>
>  >> If I'm right so far I would like to come this as a suggestion.
>  >>
>  >> I also have to thank you all for postgis.
>  >> It has been a very nice experience to start handling the gis
analysing
>  >> and processing in database-environment.
>  >> My next step is to try to manage any of the procedural languages.
Then
>  >> I guess I can do just anything with all the points and polygons
out
> there
>  >:-).
>  >>
>  >> /Nicklas
>  >>
>  >>
>  >>
----------------------------------------------------------------------
>  >> --
>  >>
>  >> _______________________________________________
>  >> postgis-users mailing list
>  >> postgis-users at postgis.refractions.net
>  >> http://postgis.refractions.net/mailman/listinfo/postgis-users
>  >
>  >_______________________________________________
>  >postgis-users mailing list
>  >postgis-users at postgis.refractions.net
>  >http://postgis.refractions.net/mailman/listinfo/postgis-users
>  >
>  >
>  >__________ Information from ESET NOD32 Antivirus, version of virus
> signature
>  >database 3842 (20090210) __________
>  >
>  >The message was checked by ESET NOD32 Antivirus.
>  >
>  >http://www.eset.com
>  >
>  >
>  >
>  >
>  >_______________________________________________
>  >postgis-users mailing list
>  >postgis-users at postgis.refractions.net
>  >http://postgis.refractions.net/mailman/listinfo/postgis-users
>  >
>  >
>
>
>
------------------------------------------------------------------------
>
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users

_______________________________________________
postgis-users mailing list
postgis-users at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users
-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.

```