[postgis-devel] Distance patch

[Nicklas Avén]

Now I have committed something for the empty geometries. Please take a look I use MAXFLOAT as startvalue when seeking mindistance. Is that ok?then I check if mindistance still is MAXFLOAT after iterating through all subgeometries, then it should return null. is that ok way of doing it? I also check so no empty geometries will go into the calculations but just be returned and not touching mindistance. st_distance, st_dwithin are now supposed to return according to the empty geometry document.st_max_distance and st_dfyllywithin should behave the same way as their corresponding above.st_shortestline, st_closestpoint and st_longestline should return null /Nicklas 

2009-11-21 Nicklas Avén wrote:

>Sounds great> >I'm working on the empty geometry handling. Didn't have time earlier today but should be done in some hours.> >About the timing I'm little supprized that the difference wasn't bigger. I thought you would pass 10 times faster at maybe 30 aginst 30 vertexes. But that also depends on how close to each other the geometries are. How many of them getting overlapping bounding boxes and because of that uses the old calculation. The new algoritm is more unpredictable in speed since it depends on how the geometries is "seen" from each other.> >Thanks>Nicklas> >
>
> 2009-11-21 Paragon Corporation wrote:
>
> Paul and Nicklas,
> >The patch looks good to me. So if Nicklas is ready I would say its good to
> >go in.
> >
> >Nicklas -- your subgeom change fixed the anomalies I started to notice (with
> >my neig parcel dist checks). I tested on a wider
> >Distribution of geometries and they look fine. There are a few cases (not
> >sure the percentage since I have to have the query run for a while just to
> >pick up one where the diff from old and new < 0.
> >
> >In the cases where it is the diff is about e-9 (worst case) to e-11. So
> >around the range when the floating precision artifacts cloud the numbers
> >anyway.
> >
> >Here are my test results using sample linestrings and polygons (these are
> >not multi though since the data that had a good mix didn't have multis) The
> >n-n2 range are the number of points (so testing distance between lines of
> >10-20 points vs. polygons of 10-20 points). 
> >
> >-- (0-9, 5000 recs: new 312 ms, old 344 ms (they both fluctuate between
> >213ms and 625 ms so hard to tell which is faster)
> >-- (10-20, 5000 recs: new 344 ms, old: 750 ms)
> >-- (20-40, 5000 recs: new 359 ms, old: 2344 ms)
> >-- (41-50, 5000 recs: new 860 ms, old: 5609 ms)
> >-- (51-60, 5000 recs: new 1828 ms, old: 9984 ms)
> >-- (61-70, 5000 recs: new 1922 ms, old: 12657 ms)
> >
> >
> >Regarding the other issue that Nicklas brought up about how to test these
> >things.
> >I do find being able to run both a PostGIS 1.4 distance and PostGIS 1.5
> >distance in the same database very useful for testing. Its better than
> >defining a dist_old in postgis code because its one less thing we have to
> >remove and also doesn't run the risk of not being able to test old behavior
> >that has changed because of core code base changes.
> >
> >As to whether this is useful in production to say run new PostGIS 1.5
> >functions you badly want and still maintain your PostGIS 1.3/1.4 -- Yes and
> >No.
> >
> >The person in me that just wants a single feature (say faster dist or better
> >distance spheroid functions) from say 1.5 wihtout rocking my exisitng
> >installs says Yes.
> >The person in me that likes consistency and ease of upgrade says No. 
> >
> >So I guess we could say its possible to hack your PostGIS into a mutant
> >1.3/1.5 or 1.4/1.5 install but we don't support it.
> >
> >Thanks,
> >Regina
> >
> >
> >
> >_______________________________________________
> >postgis-devel mailing list
> >postgis-devel at postgis.refractions.net
> >postgis.refractions.net/mailman/listinfo/postgis-devel
> >
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20091122/7b4242f4/attachment.html>