[postgis-devel] Distance patch

[Paul Ramsey]

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
<nicklas.aven at jordogskog.no> 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
>
>