[postgis-devel] Distance patch

Sun Nov 22 15:00:52 PST 2009

I have done some more changes in error and debig handling. Have not done any testing afterwards, but I haven't done anything that should affect the logic. From my point of view it is time to merge if you others think so. /Nicklas
2009-11-22 Paul Ramsey wrote:

Well, avoid the double == double construction. The thing that makes it
>really ugly though is the combination of a measure value with a mode
>value. Basically your mode, which is a switch has a hidden
>mathematical meaning, which is non-obvious. This construction is more
>verbose, but more obvious in intent:
>
>double maxdistance = ( mode == DIST2D_MIN ? -1.0 * MAXFLOAT : MAXFLOAT );
>
>P.
>
>On Sun, Nov 22, 2009 at 3:27 AM, Nicklas Avén
> wrote:
>> 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
>>>
>>>
>> _______________________________________________
>> 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/20091123/755cafac/attachment.html>