[postgis-devel] Distance patch

[Nicklas Avén]

yes, I see too that this is ugly. Is there a common,better way of doing it? The reason for todays code is I try to keep shortest and longest line to share the same function lw_dist2d_distanceline. My thought also was that MAXFLOAT is harmless with or without sign since it is stored in a double. just a thought.  I will try the IRC /Nicklas

2009-11-22 Paul Ramsey wrote:

This gives me the willies:
>
> if (thedl.distance == mode * MAXFLOAT)
>
>At a minimum, reverse the test so that this is the test
>
> if (thedl.distance < mode * MAXFLOAT)
>
>P.
>
>On Sat, Nov 21, 2009 at 5:46 PM, Nicklas Avén
> wrote:
>> 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
>>> >
>>> >
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
>>
>_______________________________________________
>postgis-devel mailing list
>postgis-devel at postgis.refractions.net
>http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20091122/d716ecc2/attachment.html>