<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">another, "what's the best way of doing it" question</div>
<div align="left"> </div>
<div align="left">As the code looks now I don't know how to lift an error message from the functions deeper down. The only thing flaffinf the error is the returning integer. Noe it returns 0 for error and 1 for succes. Maybe it is better to use the return as a response of the question: error? instead of : success? and use LW_FALSE when there is no error and LW_TRUE or some other error code to return when there is an error. I mean a success is a success not much to comment, but an error raises the need of more information.</div>
<div align="left">So, should I switch, so 0 (LW_FALSE) means success or no error, and any other integer means some error.</div>
<div align="left"> </div>
<div align="left">Or should I put lwerror where the error occurs. As I understand it lwerror stops everything, so then the LW_TRUE, LW_FALSE thing will not be use for more than the uncatched cases.</div>
<div align="left"> </div>
<div align="left">Nicklas<br />
<br />
2009-11-22 Paul Ramsey wrote:<br />
<br />
lwerror() isn't actually all that great at identifying where things<br />
>have gone wrong, so this construction,<br />
><br />
> lwerror("Something went wrong");<br />
><br />
>is going to be very un-useful to people who actually cause an error<br />
>condition. At a minimum, identify the function within which you are<br />
>called.<br />
><br />
>(Mark, can we steal some of the magic from LWDEBUG() for lwerror in<br />
>terms of function/line number identification?)<br />
><br />
>P.<br />
><br />
>On Sat, Nov 21, 2009 at 5:46 PM, Nicklas Avén<br />
>
<nicklas.aven@jordogskog.no></nicklas.aven@jordogskog.no> 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 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 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. I<br />
>> thought you would pass 10 times faster at maybe 30 aginst 30 vertexes. But<br />
>> that also depends on how close to each other the geometries are. How many 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 (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 numbers<br />
>>> >anyway.<br />
>>> ><br />
>>> >Here are my test results using sample linestrings and polygons (these 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 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 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 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 />
></div>
</body>
</html>