[postgis-devel] Distance patch
pramsey at cleverelephant.ca
Sat Nov 21 18:02:52 PST 2009
lwerror() isn't actually all that great at identifying where things
have gone wrong, so this construction,
lwerror("Something went wrong");
is going to be very un-useful to people who actually cause an error
condition. At a minimum, identify the function within which you are
(Mark, can we steal some of the magic from LWDEBUG() for lwerror in
terms of function/line number identification?)
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
> 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.
>> 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
>> >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
>> >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
>> >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.
>> >postgis-devel mailing list
>> >postgis-devel at postgis.refractions.net
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
More information about the postgis-devel