[postgis-devel] Distance patch

[Paul Ramsey]

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