st_distance, shortestline (, st_maxdistance)

[post...@…]

This is not a defect report ! But I had no choise but that.

It's a suggestion about some change in : st_distance(geometry,geometry) and a new function shortestline(geometry, geometry) and a try to get st_max_distance(geometry,geometry) work.

The reason for putting them together here is that they all use the same functions.

I'm new to this som you have to excuse some amateur mistakes.

I've struggled to make to patches to attach.

The on shortestline is working and adds the function shortestline like: Create OR REPLACE FUNCTION shortestline(geometry,geometry) RETURNS geometry AS '$libdir/postgis-1.4', 'LWGEOM_shortestline2d' LANGUAGE 'c' IMMUTABLE STRICT;

it also increases the speed of st_distance , at least in the few tests I have done.

The other patch maxdistance.patch is not working. I really don't understand why, but I think the idea of approach is good .

/Nicklas

[post...@…]

There were a lot of bugs in my first posting. Now everything seems to work as it should in my small tests. This patch includes:

1) a new approach to st_distance (and st_dwithin) 2) st_maxdistance that I think seems to work properly 3) st_shortestline a new function that returns a line from the points where st_distance is measured. 4) st_longestline, the same as shortestline but to the line from maxdistance.

I have had some problem with my compilation bahaving differnt from time to time but noe I think it seems to work.

There is a lot of naming that is just temporary and I don't know what conventions to follow.

hope for some feedback Nicklas Avén

[pramsey]

Check out the STYLE document at the source root.

[post...@…]

Some news

I've done som changes som now I think the st_maxdistance function handles polygons with holes. It ignores every intersection and just continue to find the to points most far from each other in the two input geometries. A nice result from that is that if you input the same geometry both as geometry1 and geometry2 you get the longest distance from one part of the geometry to another part.

I have also atached some images showing my results with st_shortestline and st_longestline. The length of these lines is the same as the distances of st_distance and st_maxdistance. I just made images of some polygonexamples, but I thing it seems to work propably with points and lines too.

I have also tried to follow the Style document and I have done some renaming and commenting. I guess my renaming makes the patch so much bigger now.

the syntax for the new functions is just: st_maxdistance(geometry,geometry) st_shortestline(geometry,geometry) st_longestline(geometry,geometry)

Nicklas Avén

[lr1234567]

Nicklas this all sounds good. I'm hoping to try this out on a couple of use cases once I have the other testing we are doing done for our frozen release.

One small thing and people can correct me if they feel this is unnecessary.

Can you split this out. By that I mean.

1) The st_max_distance function I consider a bug fix since we have a non-working stub function for it already, not a new function so given our new unspoken policy it is probably fine to push this to 1.3.7, 1.4.1 2) st_distance enhancements since it doesn't affect exposed api can also be considered 1.3.7 , 1.4.1 material

3) but exposing the other new functions even though it sounds like they support max distance, are new functions and those would require we wait till 1.5 or gasp 2.0.

Is there anyway you can separate these out even if you just don't include the new functions in postgis.inc.sql.c.

Mark, Paul or Kevin can correct me if I am wrong on this request.

Thanks, Regina

[lr1234567]

Slight clarification. This will sound kind of odd.

My feeling is include the new functions as dependency functions, but don't expose them in the .sql file. It sounds petty I guess, but would make I think dropping in a new binary easier for people.

Thanks, Regina

[post...@…]

Regina, sounds ok I think

I have commented out the longest and shortest line-functions in postgis.inc.sql.c

Then I have made I very small change in moving some declarations because of a warning that ISO C90 don't want mixed declarations and code. So now I get no new warnings when I'm compiling.

One question:

In the function st_shortestline, if the two geometries intersect the returned line has both the start and the end-point in the first intersection-point. I thing that's a logical result and useble with st_startpoint or st_endpoint to identify the intersection if distance is 0. But there are severel occasions when the distance is 0 but there is no intersection-point like one geometry inside polygon. Now you get a line with starting and ending at origo. That's not good. Is a empty geometry the best or…

/Nicklas Avén

[robe]

Nicklas, I think in those cases, its better to return null rather than an empty geometry. The main reasons I think its best is that I think that's the way the other functions in PostGIS work when no valid geometry can be given (such as when you ST_Simplify something too much).

The other reason is that if someone is using this to insert/update a geometry column, then most likely they have a constraint that allows null or a linestring or multilinestring. If you return empty geometry, they would need to do checking to check if its empty before they can insert — which adds another level of annoyance.

The 3rd reason is that most geos functions don't like GEOMETRY collections and barf when they see one — so if it is used as a preprocessor for something else — it may halt execution. (and an empty geometry I think is considered a geometry collection — or hmm maybe we really do support the concept of an empty LINESTRING though not sure what GEOS does with such a thing). I think Paul may have been working on that.

Alternatively I suppose you could return a point (hmm or maybe not since you would still have the annoyance of checking and the function is after all called the shortest_line).

[post...@…]

Here is a new patch in wich I try to preserve the order of incoming geometries. If that order isn't preserved st_shortestline will be quite useless.

I'm not totally sure that I have succeeded to think of all possibilities where the order will be mixed up. But I will look through it some more.

In this patch the bug discussed in #146 should be fixed to.

Now, let me just give an example of the use of the function st_shortestline, why I think it should be in postgis. It is efficient and simple to use for snapping. Let's say you have an GPS-point taken on a road some where. The point will not be exactly on the road beacause of precision issues both to the GPS and the map. To find the closest point to the gps-point on the road-line using st_shortestline we just do: SELECT st_endpoint(ST_shortestline(g1,g2)) As pointonroad from (select ST_geomFromEWKT('POINT(2 4)') As g1, ST_geomFromEWKT('LINESTRING(1 2, 2 5)') As g2) a;

Here the order of inputing geometrys to st_shortestline is of importance.

/Nicklas Avén