<html>
<head>
<title></title>
<meta name="GENERATOR" content="MSHTML 8.00.6001.18852"></meta>
<meta name="SKYPE_FRAMEID" content="HBROAMAKDT"></meta>
<meta id="skype_v3_tb_marker_id" name="SKYPE_PARSING_HAS_FINISHED" content="metacontent"></meta>
</head>
<body>
<div align="left">I have done some more changes in error and debig handling.</div>
<div align="left"> </div>
<div align="left">Have not done any testing afterwards, but I haven't done anything that should affect the logic.</div>
<div align="left"> </div>
<div align="left">From my point of view it is time to merge if you others think so.</div>
<div align="left"> </div>
<div align="left">/Nicklas</div>
<div align="left"><br />
2009-11-22 Paul Ramsey wrote:<br />
<br />
Well, avoid the double == double construction. The thing that makes it<br />
>really ugly though is the combination of a measure value with a mode<br />
>value. Basically your mode, which is a switch has a hidden<br />
>mathematical meaning, which is non-obvious. This construction is more<br />
>verbose, but more obvious in intent:<br />
><br />
>double maxdistance = ( mode == DIST2D_MIN ? -1.0 * MAXFLOAT : MAXFLOAT );<br />
><br />
>P.<br />
><br />
>On Sun, Nov 22, 2009 at 3:27 AM, Nicklas Avén<br />
>
<nicklas.aven@jordogskog.no></nicklas.aven@jordogskog.no> wrote:<br />
>> yes, I see too that this is ugly. Is there a common,better way of doing it?<br />
>> The reason for todays code is I try to keep shortest and longest line to<br />
>> share the same function lw_dist2d_distanceline. My thought also was that<br />
>> MAXFLOAT is harmless with or without sign since it is stored in a double.<br />
>> just a thought.<br />
>><br />
>><br />
>> I will try the IRC<br />
>><br />
>> /Nicklas<br />
>><br />
>> 2009-11-22 Paul Ramsey wrote:<br />
>><br />
>> This gives me the willies:<br />
>>><br />
>>> if (thedl.distance == mode * MAXFLOAT)<br />
>>><br />
>>>At a minimum, reverse the test so that this is the test<br />
>>><br />
>>> if (thedl.distance < mode * MAXFLOAT)<br />
>>><br />
>>>P.<br />
>>><br />
>>>On Sat, Nov 21, 2009 at 5:46 PM, Nicklas Avén<br />
>>> wrote:<br />
>>>> Now I have committed something for the empty geometries.<br />
>>>><br />
>>>> Please take a look<br />
>>>><br />
>>>> I use MAXFLOAT as startvalue when seeking mindistance. Is that ok?<br />
>>>> then I check if mindistance still is MAXFLOAT after iterating through all<br />
>>>> subgeometries, then it should return null. is that ok way of doing it?<br />
>>>><br />
>>>> I also check so no empty geometries will go into the calculations but<br />
>>>> just<br />
>>>> be returned and not touching mindistance.<br />
>>>><br />
>>>> st_distance, st_dwithin are now supposed to return according to the empty<br />
>>>> geometry document.<br />
>>>> st_max_distance and st_dfyllywithin should behave the same way as their<br />
>>>> corresponding above.<br />
>>>> st_shortestline, st_closestpoint and st_longestline should return null<br />
>>>><br />
>>>> /Nicklas<br />
>>>><br />
>>>><br />
>>>> 2009-11-21 Nicklas Avén wrote:<br />
>>>><br />
>>>>><br />
>>>> Sounds great<br />
>>>>><br />
>>>><br />
>>>>><br />
>>>> I'm working on the empty geometry handling. Didn't have time earlier<br />
>>>> today<br />
>>>> but should be done in some hours.<br />
>>>>><br />
>>>><br />
>>>>><br />
>>>> About the timing I'm little supprized that the difference wasn't bigger.<br />
>>>> I<br />
>>>> thought you would pass 10 times faster at maybe 30 aginst 30 vertexes.<br />
>>>> But<br />
>>>> that also depends on how close to each other the geometries are. How many<br />
>>>> of<br />
>>>> them getting overlapping bounding boxes and because of that uses the old<br />
>>>> calculation. The new algoritm is more unpredictable in speed since it<br />
>>>> depends on how the geometries is "seen" from each other.<br />
>>>>><br />
>>>><br />
>>>>><br />
>>>> Thanks<br />
>>>>><br />
>>>> Nicklas<br />
>>>>><br />
>>>><br />
>>>>><br />
>>>>><br />
>>>>> 2009-11-21 Paragon Corporation wrote:<br />
>>>>><br />
>>>>> Paul and Nicklas,<br />
>>>>> >The patch looks good to me. So if Nicklas is ready I would say its good<br />
>>>>> > to<br />
>>>>> >go in.<br />
>>>>> ><br />
>>>>> >Nicklas -- your subgeom change fixed the anomalies I started to notice<br />
>>>>> > (with<br />
>>>>> >my neig parcel dist checks). I tested on a wider<br />
>>>>> >Distribution of geometries and they look fine. There are a few cases<br />
>>>>> > (not<br />
>>>>> >sure the percentage since I have to have the query run for a while just<br />
>>>>> > to<br />
>>>>> >pick up one where the diff from old and new < 0.<br />
>>>>> ><br />
>>>>> >In the cases where it is the diff is about e-9 (worst case) to e-11. So<br />
>>>>> >around the range when the floating precision artifacts cloud the<br />
>>>>> > numbers<br />
>>>>> >anyway.<br />
>>>>> ><br />
>>>>> >Here are my test results using sample linestrings and polygons (these<br />
>>>>> > are<br />
>>>>> >not multi though since the data that had a good mix didn't have multis)<br />
>>>>> > The<br />
>>>>> >n-n2 range are the number of points (so testing distance between lines<br />
>>>>> > of<br />
>>>>> >10-20 points vs. polygons of 10-20 points).<br />
>>>>> ><br />
>>>>> >-- (0-9, 5000 recs: new 312 ms, old 344 ms (they both fluctuate between<br />
>>>>> >213ms and 625 ms so hard to tell which is faster)<br />
>>>>> >-- (10-20, 5000 recs: new 344 ms, old: 750 ms)<br />
>>>>> >-- (20-40, 5000 recs: new 359 ms, old: 2344 ms)<br />
>>>>> >-- (41-50, 5000 recs: new 860 ms, old: 5609 ms)<br />
>>>>> >-- (51-60, 5000 recs: new 1828 ms, old: 9984 ms)<br />
>>>>> >-- (61-70, 5000 recs: new 1922 ms, old: 12657 ms)<br />
>>>>> ><br />
>>>>> ><br />
>>>>> >Regarding the other issue that Nicklas brought up about how to test<br />
>>>>> > these<br />
>>>>> >things.<br />
>>>>> >I do find being able to run both a PostGIS 1.4 distance and PostGIS 1.5<br />
>>>>> >distance in the same database very useful for testing. Its better than<br />
>>>>> >defining a dist_old in postgis code because its one less thing we have<br />
>>>>> > to<br />
>>>>> >remove and also doesn't run the risk of not being able to test old<br />
>>>>> > behavior<br />
>>>>> >that has changed because of core code base changes.<br />
>>>>> ><br />
>>>>> >As to whether this is useful in production to say run new PostGIS 1.5<br />
>>>>> >functions you badly want and still maintain your PostGIS 1.3/1.4 -- Yes<br />
>>>>> > and<br />
>>>>> >No.<br />
>>>>> ><br />
>>>>> >The person in me that just wants a single feature (say faster dist or<br />
>>>>> > better<br />
>>>>> >distance spheroid functions) from say 1.5 wihtout rocking my exisitng<br />
>>>>> >installs says Yes.<br />
>>>>> >The person in me that likes consistency and ease of upgrade says No.<br />
>>>>> ><br />
>>>>> >So I guess we could say its possible to hack your PostGIS into a mutant<br />
>>>>> >1.3/1.5 or 1.4/1.5 install but we don't support it.<br />
>>>>> ><br />
>>>>> >Thanks,<br />
>>>>> >Regina<br />
>>>>> ><br />
>>>>> ><br />
>>>>> ><br />
>>>>> >_______________________________________________<br />
>>>>> >postgis-devel mailing list<br />
>>>>> >postgis-devel@postgis.refractions.net<br />
>>>>> >postgis.refractions.net/mailman/listinfo/postgis-devel<br />
>>>>> ><br />
>>>>> ><br />
>>>> _______________________________________________<br />
>>>> postgis-devel mailing list<br />
>>>> postgis-devel@postgis.refractions.net<br />
>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel<br />
>>>><br />
>>>><br />
>>>_______________________________________________<br />
>>>postgis-devel mailing list<br />
>>>postgis-devel@postgis.refractions.net<br />
>>>http://postgis.refractions.net/mailman/listinfo/postgis-devel<br />
>>><br />
>>><br />
>> _______________________________________________<br />
>> postgis-devel mailing list<br />
>> postgis-devel@postgis.refractions.net<br />
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel<br />
>><br />
>><br />
>_______________________________________________<br />
>postgis-devel mailing list<br />
>postgis-devel@postgis.refractions.net<br />
>http://postgis.refractions.net/mailman/listinfo/postgis-devel<br />
><br />
></div>
</body>
</html>