tag:old.nabble.com,2006:forum-1221Nabble - PostGIS2009-11-23T03:55:11ZPostGIS adds support for geographic objects to the PostgreSQL object-relational database. PostGIS home is <a href="http://postgis.refractions.net/" target="_top" rel="nofollow">here</a>.tag:old.nabble.com,2006:post-26476752Re: The Road to 1.52009-11-23T03:55:11Z2009-11-23T03:55:11ZMark Cave-Ayland-3Paul Ramsey wrote:
<br><br>> #204, #110, #251 are on Mark's plate to finish for this milestone
<br><br>Yes, I've already made a start on this and am busy in the middle of
<br>ripping the guts out of shp2pgsql and friends to make this happen...
<br><br><br>ATB,
<br><br>Mark.
<br><br>--
<br>Mark Cave-Ayland - Senior Technical Architect
<br>PostgreSQL - PostGIS
<br>Sirius Corporation plc - control through freedom
<br><a href="http://www.siriusit.co.uk" target="_top" rel="nofollow">http://www.siriusit.co.uk</a><br>t: +44 870 608 0063
<br><br>Sirius Labs: <a href="http://www.siriusit.co.uk/labs" target="_top" rel="nofollow">http://www.siriusit.co.uk/labs</a><br>_______________________________________________
<br>postgis-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26476752&i=0" target="_top" rel="nofollow">postgis-devel@...</a>
<br><a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_top" rel="nofollow">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br><p>From forum: <a href="http://old.nabble.com/PostGIS---Dev-f1222.html" embed="fixTarget[1222]" target="_top" >PostGIS - Dev</a></p>tag:old.nabble.com,2006:post-26475014Re: [PostGIS] #273: ST_GeomFromGML crashes in Windows compiled in MingW2009-11-23T01:40:41Z2009-11-23T01:40:41ZNicklas Avén<html>
<head>
<title></title>
<meta name="GENERATOR" content="MSHTML 8.00.6001.18852"></meta>
</head>
<body>
<div align="left">I compiled the LIBXML2 library with a lot of warnings, do you have them too Regina or should I post them, Oliver.</div>
<div align="left">When I should test it I couldn't find any sql.definition of the function ST_GeomFromGML. As I see in postgis.sql.in.c that is because LIBXML2 isn't found. So I guess the compilation didn't sucess. I will see if I get time to try later today.</div>
<div align="left"> </div>
<div align="left"> </div>
<div align="left">/Nicklas</div>
<div align="left"> </div>
<div align="left"> </div>
<div align="left"><br />
2009-11-23 PostGIS wrote:<br />
<br />
#273: ST_GeomFromGML crashes in Windows compiled in MingW<br />
>----------------------+-----------------------------------------------------<br />
> Reporter: robe | Owner: colivier <br />
> Type: defect | Status: new <br />
> Priority: medium | Milestone: PostGIS 1.5.0<br />
> Component: postgis | Version: trunk <br />
>Resolution: | Keywords: <br />
>----------------------+-----------------------------------------------------<br />
>Comment (by robe):<br />
><br />
> Strange. Maybe its something else I install getting in the way or I'm not<br />
> compiling libxml right. I have another box I can try on later. Nicklas<br />
> -- you have a mingw install -- if its not asking too much -- can you try<br />
> compiling and doing the simple<br />
><br />
><br />
> {{{<br />
> SELECT<br />
> ST_GeomFromGML('
<gml:point>
<gml:coordinates>1,2</gml:coordinates></gml:point>')<br />
> }}}<br />
> to see if it works.<br />
><br />
> Olivier - what is your mingw gcc and mingw/msys versions? On my gcc 3.5<br />
> box, I was able to compile and install without errors (except libxml make<br />
> checks fail), but got crashes when doing the above test. On my upgraded<br />
> mingw running gcc 4.4, I can't compile libxml at all.<br />
><br />
>-- <br />
>Ticket URL:
<http: 273#comment:13 ticket postgis trac.osgeo.org></http:><br />
>PostGIS
<http: postgis trac.osgeo.org></http:><br />
>The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.<br />
>_______________________________________________<br />
>postgis-devel mailing list<br />
><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26475014&i=0" target="_top" rel="nofollow">postgis-devel@...</a><br />
>http://postgis.refractions.net/mailman/listinfo/postgis-devel<br />
><br />
></div>
</body>
</html>
<br />_______________________________________________
<br>postgis-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26475014&i=1" target="_top" rel="nofollow">postgis-devel@...</a>
<br><a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_top" rel="nofollow">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br><p>From forum: <a href="http://old.nabble.com/PostGIS---Dev-f1222.html" embed="fixTarget[1222]" target="_top" >PostGIS - Dev</a></p>tag:old.nabble.com,2006:post-26473569Re: [PostGIS] #240: ST_SimplifyPreserveTopology documentation unclear on intersections within a MultiPolygon2009-11-22T23:11:34Z2009-11-22T23:11:34ZPostGIS-4#240: ST_SimplifyPreserveTopology documentation unclear on intersections within a
<br>MultiPolygon
<br>----------------------+-----------------------------------------------------
<br> Reporter: perchrh | Owner: robe
<br> Type: defect | Status: new
<br> Priority: medium | Milestone: PostGIS 1.5.0
<br> Component: postgis | Version:
<br>Resolution: | Keywords:
<br>----------------------+-----------------------------------------------------
<br>Comment (by perchrh):
<br><br> In the ESRI shapefile standard, a Record with shapetype Polygon is a
<br> collection of zero or more Rings (in other terms: a MultiPolygon
<br> containing multiple Polygons). The rings may intersect each other and
<br> cannot self-intersect.
<br><br> It is clear that ST_SimplifyPreserveTopology doesn't introduce self-
<br> intersections and doesn't introduce intersections between Polygons if
<br> there were none in the input.
<br><br> My question, that I didn't manage to get answered by a quick look at the
<br> code is, is the processing of these valid MultiPolygons with intersecting
<br> Polygons guaranteed to result in a MultiPolygon with no new intersections?
<br> Or does it just guarantee that the intersection count will not be higher
<br> than in the input? To put it another way, if I have a MultiPolygon with
<br> three polygons, two of them intersecting each other (A and B), is it
<br> possible that B and C will intersect after ST_SimplifyPreserveTopology?
<br><br>--
<br>Ticket URL: <<a href="http://trac.osgeo.org/postgis/ticket/240#comment:7" target="_top" rel="nofollow">http://trac.osgeo.org/postgis/ticket/240#comment:7</a>>
<br>PostGIS <<a href="http://trac.osgeo.org/postgis/" target="_top" rel="nofollow">http://trac.osgeo.org/postgis/</a>>
<br>The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
<br>_______________________________________________
<br>postgis-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26473569&i=0" target="_top" rel="nofollow">postgis-devel@...</a>
<br><a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_top" rel="nofollow">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br><p>From forum: <a href="http://old.nabble.com/PostGIS---Dev-f1222.html" embed="fixTarget[1222]" target="_top" >PostGIS - Dev</a></p>tag:old.nabble.com,2006:post-26471752Re: [PostGIS] #273: ST_GeomFromGML crashes in Windows compiled in MingW2009-11-22T18:03:09Z2009-11-22T18:03:09ZPostGIS-4#273: ST_GeomFromGML crashes in Windows compiled in MingW
<br>----------------------+-----------------------------------------------------
<br> Reporter: robe | Owner: colivier
<br> Type: defect | Status: new
<br> Priority: medium | Milestone: PostGIS 1.5.0
<br> Component: postgis | Version: trunk
<br>Resolution: | Keywords:
<br>----------------------+-----------------------------------------------------
<br>Comment (by robe):
<br><br> One thing I forgot to mention. I was testing against the Enterprisedb
<br> compiled PostgreSQL 8.3/8.4, not my mingw compiled version. I do that
<br> because sometimes they behave differently. For example plr works fine
<br> under my mingw compiled postgresql 84, but I for the life of me can't even
<br> get it to load in the visual c++ compiled EDB packaged PostgreSQL. So
<br> that I know I will eventually have to bite the bullet and figure out how
<br> to compile plr under vc++.
<br><br>--
<br>Ticket URL: <<a href="http://trac.osgeo.org/postgis/ticket/273#comment:14" target="_top" rel="nofollow">http://trac.osgeo.org/postgis/ticket/273#comment:14</a>>
<br>PostGIS <<a href="http://trac.osgeo.org/postgis/" target="_top" rel="nofollow">http://trac.osgeo.org/postgis/</a>>
<br>The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
<br>_______________________________________________
<br>postgis-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26471752&i=0" target="_top" rel="nofollow">postgis-devel@...</a>
<br><a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_top" rel="nofollow">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br><p>From forum: <a href="http://old.nabble.com/PostGIS---Dev-f1222.html" embed="fixTarget[1222]" target="_top" >PostGIS - Dev</a></p>tag:old.nabble.com,2006:post-26471674Re: [PostGIS] #273: ST_GeomFromGML crashes in Windows compiled in MingW2009-11-22T17:53:15Z2009-11-22T17:53:15ZPostGIS-4#273: ST_GeomFromGML crashes in Windows compiled in MingW
<br>----------------------+-----------------------------------------------------
<br> Reporter: robe | Owner: colivier
<br> Type: defect | Status: new
<br> Priority: medium | Milestone: PostGIS 1.5.0
<br> Component: postgis | Version: trunk
<br>Resolution: | Keywords:
<br>----------------------+-----------------------------------------------------
<br>Comment (by robe):
<br><br> Strange. Maybe its something else I install getting in the way or I'm not
<br> compiling libxml right. I have another box I can try on later. Nicklas
<br> -- you have a mingw install -- if its not asking too much -- can you try
<br> compiling and doing the simple
<br><br><br> {{{
<br> SELECT
<br> ST_GeomFromGML('<gml:Point><gml:coordinates>1,2</gml:coordinates></gml:Point>')
<br> }}}
<br> to see if it works.
<br><br> Olivier - what is your mingw gcc and mingw/msys versions? On my gcc 3.5
<br> box, I was able to compile and install without errors (except libxml make
<br> checks fail), but got crashes when doing the above test. On my upgraded
<br> mingw running gcc 4.4, I can't compile libxml at all.
<br><br>--
<br>Ticket URL: <<a href="http://trac.osgeo.org/postgis/ticket/273#comment:13" target="_top" rel="nofollow">http://trac.osgeo.org/postgis/ticket/273#comment:13</a>>
<br>PostGIS <<a href="http://trac.osgeo.org/postgis/" target="_top" rel="nofollow">http://trac.osgeo.org/postgis/</a>>
<br>The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
<br>_______________________________________________
<br>postgis-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26471674&i=0" target="_top" rel="nofollow">postgis-devel@...</a>
<br><a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_top" rel="nofollow">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br><p>From forum: <a href="http://old.nabble.com/PostGIS---Dev-f1222.html" embed="fixTarget[1222]" target="_top" >PostGIS - Dev</a></p>tag:old.nabble.com,2006:post-26470527Re: Distance patch2009-11-22T15:00:52Z2009-11-22T15:00:52ZNicklas Avén<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 />
>>>>> ><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26470527&i=0" target="_top" rel="nofollow">postgis-devel@...</a><br />
>>>>> >postgis.refractions.net/mailman/listinfo/postgis-devel<br />
>>>>> ><br />
>>>>> ><br />
>>>> _______________________________________________<br />
>>>> postgis-devel mailing list<br />
>>>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26470527&i=1" target="_top" rel="nofollow">postgis-devel@...</a><br />
>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel<br />
>>>><br />
>>>><br />
>>>_______________________________________________<br />
>>>postgis-devel mailing list<br />
>>><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26470527&i=2" target="_top" rel="nofollow">postgis-devel@...</a><br />
>>>http://postgis.refractions.net/mailman/listinfo/postgis-devel<br />
>>><br />
>>><br />
>> _______________________________________________<br />
>> postgis-devel mailing list<br />
>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26470527&i=3" target="_top" rel="nofollow">postgis-devel@...</a><br />
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel<br />
>><br />
>><br />
>_______________________________________________<br />
>postgis-devel mailing list<br />
><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26470527&i=4" target="_top" rel="nofollow">postgis-devel@...</a><br />
>http://postgis.refractions.net/mailman/listinfo/postgis-devel<br />
><br />
></div>
</body>
</html>
<br />_______________________________________________
<br>postgis-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26470527&i=5" target="_top" rel="nofollow">postgis-devel@...</a>
<br><a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_top" rel="nofollow">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br><p>From forum: <a href="http://old.nabble.com/PostGIS---Dev-f1222.html" embed="fixTarget[1222]" target="_top" >PostGIS - Dev</a></p>tag:old.nabble.com,2006:post-26468173Re: [PostGIS] #273: ST_GeomFromGML crashes in Windows compiled in MingW2009-11-22T10:47:25Z2009-11-22T10:47:25ZPostGIS-4#273: ST_GeomFromGML crashes in Windows compiled in MingW
<br>----------------------+-----------------------------------------------------
<br> Reporter: robe | Owner: colivier
<br> Type: defect | Status: new
<br> Priority: medium | Milestone: PostGIS 1.5.0
<br> Component: postgis | Version: trunk
<br>Resolution: | Keywords:
<br>----------------------+-----------------------------------------------------
<br>Comment (by colivier):
<br><br> Regina,
<br><br> You're right the install problem was the dual GEOS install.
<br> I (finnaly) succeed to install the whole stuff with Mingw (not exactly a
<br> piece of cake) !
<br><br><br> With my install everything is fine with in_gml.sql and in_kml.sql
<br><br> Postgis: r4813
<br> Geos: 3.2.0 RC1
<br> Libxml2: 2.7.6
<br><br> I really suspect you're libxml2 installation to be the problem. Is it
<br> possible for you (or someone else) to test it on an another box ?
<br><br>--
<br>Ticket URL: <<a href="http://trac.osgeo.org/postgis/ticket/273#comment:12" target="_top" rel="nofollow">http://trac.osgeo.org/postgis/ticket/273#comment:12</a>>
<br>PostGIS <<a href="http://trac.osgeo.org/postgis/" target="_top" rel="nofollow">http://trac.osgeo.org/postgis/</a>>
<br>The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
<br>_______________________________________________
<br>postgis-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26468173&i=0" target="_top" rel="nofollow">postgis-devel@...</a>
<br><a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_top" rel="nofollow">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br><p>From forum: <a href="http://old.nabble.com/PostGIS---Dev-f1222.html" embed="fixTarget[1222]" target="_top" >PostGIS - Dev</a></p>tag:old.nabble.com,2006:post-26467325Re: Distance patch2009-11-22T09:27:14Z2009-11-22T09:27:14ZPaul Ramsey-3Well, 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><<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26467325&i=0" target="_top" rel="nofollow">nicklas.aven@...</a>> wrote:
<div class='shrinkable-quote'><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>>>>> ><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26467325&i=1" target="_top" rel="nofollow">postgis-devel@...</a>
<br>>>>> >postgis.refractions.net/mailman/listinfo/postgis-devel
<br>>>>> >
<br>>>>> >
<br>>>> _______________________________________________
<br>>>> postgis-devel mailing list
<br>>>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26467325&i=2" target="_top" rel="nofollow">postgis-devel@...</a>
<br>>>> <a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_top" rel="nofollow">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br>>>>
<br>>>>
<br>>>_______________________________________________
<br>>>postgis-devel mailing list
<br>>><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26467325&i=3" target="_top" rel="nofollow">postgis-devel@...</a>
<br>>><a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_top" rel="nofollow">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br>>>
<br>>>
<br>> _______________________________________________
<br>> postgis-devel mailing list
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26467325&i=4" target="_top" rel="nofollow">postgis-devel@...</a>
<br>> <a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_top" rel="nofollow">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br>>
<br>>
</div>_______________________________________________
<br>postgis-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26467325&i=5" target="_top" rel="nofollow">postgis-devel@...</a>
<br><a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_top" rel="nofollow">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br><p>From forum: <a href="http://old.nabble.com/PostGIS---Dev-f1222.html" embed="fixTarget[1222]" target="_top" >PostGIS - Dev</a></p>tag:old.nabble.com,2006:post-26467232Re: Distance patch2009-11-22T09:20:25Z2009-11-22T09:20:25ZPaul Ramsey-3On Sun, Nov 22, 2009 at 3:38 AM, Nicklas Avén
<br><<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26467232&i=0" target="_top" rel="nofollow">nicklas.aven@...</a>> wrote:
<br>> Or should I put lwerror where the error occurs. As I understand it lwerror
<br>> stops everything, so then the LW_TRUE, LW_FALSE thing will not be use for
<br>> more than the uncatched cases.
<br><br>It you're not going to recover from the error, put it where it happens.
<br><br>P.
<br>_______________________________________________
<br>postgis-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26467232&i=1" target="_top" rel="nofollow">postgis-devel@...</a>
<br><a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_top" rel="nofollow">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br><p>From forum: <a href="http://old.nabble.com/PostGIS---Dev-f1222.html" embed="fixTarget[1222]" target="_top" >PostGIS - Dev</a></p>tag:old.nabble.com,2006:post-26464554Re: Distance patch2009-11-22T03:38:37Z2009-11-22T03:38:37ZNicklas Avén<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 />
>>> ><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26464554&i=0" target="_top" rel="nofollow">postgis-devel@...</a><br />
>>> >postgis.refractions.net/mailman/listinfo/postgis-devel<br />
>>> ><br />
>>> ><br />
>> _______________________________________________<br />
>> postgis-devel mailing list<br />
>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26464554&i=1" target="_top" rel="nofollow">postgis-devel@...</a><br />
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel<br />
>><br />
>><br />
>_______________________________________________<br />
>postgis-devel mailing list<br />
><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26464554&i=2" target="_top" rel="nofollow">postgis-devel@...</a><br />
>http://postgis.refractions.net/mailman/listinfo/postgis-devel<br />
><br />
></div>
</body>
</html>
<br />_______________________________________________
<br>postgis-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26464554&i=3" target="_top" rel="nofollow">postgis-devel@...</a>
<br><a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_top" rel="nofollow">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br><p>From forum: <a href="http://old.nabble.com/PostGIS---Dev-f1222.html" embed="fixTarget[1222]" target="_top" >PostGIS - Dev</a></p>tag:old.nabble.com,2006:post-26464477Re: Distance patch2009-11-22T03:27:57Z2009-11-22T03:27:57ZNicklas Avén<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>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.
<div align="left"> </div>
<div align="left"> </div>
<div align="left">I will try the IRC</div>
<div align="left"> </div>
<div align="left">/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 />
>
<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 />
>>> ><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26464477&i=0" target="_top" rel="nofollow">postgis-devel@...</a><br />
>>> >postgis.refractions.net/mailman/listinfo/postgis-devel<br />
>>> ><br />
>>> ><br />
>> _______________________________________________<br />
>> postgis-devel mailing list<br />
>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26464477&i=1" target="_top" rel="nofollow">postgis-devel@...</a><br />
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel<br />
>><br />
>><br />
>_______________________________________________<br />
>postgis-devel mailing list<br />
><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26464477&i=2" target="_top" rel="nofollow">postgis-devel@...</a><br />
>http://postgis.refractions.net/mailman/listinfo/postgis-devel<br />
><br />
></div>
</body>
</html>
<br />_______________________________________________
<br>postgis-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26464477&i=3" target="_top" rel="nofollow">postgis-devel@...</a>
<br><a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_top" rel="nofollow">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br><p>From forum: <a href="http://old.nabble.com/PostGIS---Dev-f1222.html" embed="fixTarget[1222]" target="_top" >PostGIS - Dev</a></p>tag:old.nabble.com,2006:post-26462827Drawing a path using line and point tables2009-11-21T20:48:00Z2009-11-22T04:05:41ZNalin ChandrawanshaHi,
<br><br>I have two tables for roads and hospitals. I'm looking for suitable pgrouting function(s) for following scenario.
<br><br><i>Finding the closest hospital from an accident point (on a road) and draw the path.</i><br><br>Following functionality is needed.
<br><br>1. One end of the drawn path needs to start from<i> in front </i>of the closest hospital.
<br>2. Path needs to stop from the accident point on road.
<br><br>I'm new to pgrouting and appreciate your help.
<br><br><br>Thank you,
<br><br>Nalin Chandrawansha
<br><p>From forum: <a href="http://old.nabble.com/PostGIS---Dev-f1222.html" embed="fixTarget[1222]" target="_top" >PostGIS - Dev</a></p>tag:old.nabble.com,2006:post-26462328Re: [PostGIS] #317: Upgrade lwerror() to return file/linenumber information in error messages2009-11-21T18:18:16Z2009-11-21T18:18:16ZPostGIS-4#317: Upgrade lwerror() to return file/linenumber information in error messages
<br>--------------------------+-------------------------------------------------
<br> Reporter: pramsey | Owner: mcayland
<br> Type: enhancement | Status: new
<br> Priority: medium | Milestone: PostGIS Future
<br> Component: postgis | Version: trunk
<br>Resolution: | Keywords:
<br>--------------------------+-------------------------------------------------
<br>Changes (by pramsey):
<br><br> * type: defect => enhancement
<br><br>--
<br>Ticket URL: <<a href="http://trac.osgeo.org/postgis/ticket/317#comment:2" target="_top" rel="nofollow">http://trac.osgeo.org/postgis/ticket/317#comment:2</a>>
<br>PostGIS <<a href="http://trac.osgeo.org/postgis/" target="_top" rel="nofollow">http://trac.osgeo.org/postgis/</a>>
<br>The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
<br>_______________________________________________
<br>postgis-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26462328&i=0" target="_top" rel="nofollow">postgis-devel@...</a>
<br><a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_top" rel="nofollow">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br><p>From forum: <a href="http://old.nabble.com/PostGIS---Dev-f1222.html" embed="fixTarget[1222]" target="_top" >PostGIS - Dev</a></p>tag:old.nabble.com,2006:post-26462327Re: [PostGIS] #317: Upgrade lwerror() to return file/linenumber information in error messages2009-11-21T18:17:51Z2009-11-21T18:17:51ZPostGIS-4#317: Upgrade lwerror() to return file/linenumber information in error messages
<br>----------------------+-----------------------------------------------------
<br> Reporter: pramsey | Owner: mcayland
<br> Type: defect | Status: new
<br> Priority: medium | Milestone: PostGIS Future
<br> Component: postgis | Version: trunk
<br>Resolution: | Keywords:
<br>----------------------+-----------------------------------------------------
<br>Changes (by pramsey):
<br><br> * milestone: PostGIS 2.0.0 => PostGIS Future
<br><br>--
<br>Ticket URL: <<a href="http://trac.osgeo.org/postgis/ticket/317#comment:1" target="_top" rel="nofollow">http://trac.osgeo.org/postgis/ticket/317#comment:1</a>>
<br>PostGIS <<a href="http://trac.osgeo.org/postgis/" target="_top" rel="nofollow">http://trac.osgeo.org/postgis/</a>>
<br>The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
<br>_______________________________________________
<br>postgis-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26462327&i=0" target="_top" rel="nofollow">postgis-devel@...</a>
<br><a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_top" rel="nofollow">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br><p>From forum: <a href="http://old.nabble.com/PostGIS---Dev-f1222.html" embed="fixTarget[1222]" target="_top" >PostGIS - Dev</a></p>tag:old.nabble.com,2006:post-26462325[PostGIS] #317: Upgrade lwerror() to return file/linenumber information in error messages2009-11-21T18:17:37Z2009-11-21T18:17:37ZPostGIS-4#317: Upgrade lwerror() to return file/linenumber information in error messages
<br>---------------------+------------------------------------------------------
<br> Reporter: pramsey | Owner: mcayland
<br> Type: defect | Status: new
<br> Priority: medium | Milestone: PostGIS 2.0.0
<br>Component: postgis | Version: trunk
<br> Keywords: |
<br>---------------------+------------------------------------------------------
<br> Right now LWDEBUGF() returns delightful contextual information, but the
<br> errors we show to our end users do not. That means (usually) the function
<br> names get manually embedded in the error strings for content. It would be
<br> nice to have that information by default, so error strings can spend their
<br> time being descriptive (or not).
<br><br>--
<br>Ticket URL: <<a href="http://trac.osgeo.org/postgis/ticket/317" target="_top" rel="nofollow">http://trac.osgeo.org/postgis/ticket/317</a>>
<br>PostGIS <<a href="http://trac.osgeo.org/postgis/" target="_top" rel="nofollow">http://trac.osgeo.org/postgis/</a>>
<br>The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
<br>_______________________________________________
<br>postgis-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26462325&i=0" target="_top" rel="nofollow">postgis-devel@...</a>
<br><a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_top" rel="nofollow">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br><p>From forum: <a href="http://old.nabble.com/PostGIS---Dev-f1222.html" embed="fixTarget[1222]" target="_top" >PostGIS - Dev</a></p>tag:old.nabble.com,2006:post-26462247Re: Distance patch2009-11-21T18:02:52Z2009-11-21T18:02:52ZPaul Ramsey-3lwerror() 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><<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26462247&i=0" target="_top" rel="nofollow">nicklas.aven@...</a>> wrote:
<div class='shrinkable-quote'><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>>> ><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26462247&i=1" target="_top" rel="nofollow">postgis-devel@...</a>
<br>>> >postgis.refractions.net/mailman/listinfo/postgis-devel
<br>>> >
<br>>> >
<br>> _______________________________________________
<br>> postgis-devel mailing list
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26462247&i=2" target="_top" rel="nofollow">postgis-devel@...</a>
<br>> <a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_top" rel="nofollow">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br>>
<br>>
</div>_______________________________________________
<br>postgis-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26462247&i=3" target="_top" rel="nofollow">postgis-devel@...</a>
<br><a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_top" rel="nofollow">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br><p>From forum: <a href="http://old.nabble.com/PostGIS---Dev-f1222.html" embed="fixTarget[1222]" target="_top" >PostGIS - Dev</a></p>tag:old.nabble.com,2006:post-26462234Re: Distance patch2009-11-21T17:59:31Z2009-11-21T17:59:31ZPaul Ramsey-3This 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><<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26462234&i=0" target="_top" rel="nofollow">nicklas.aven@...</a>> wrote:
<div class='shrinkable-quote'><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>>> ><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26462234&i=1" target="_top" rel="nofollow">postgis-devel@...</a>
<br>>> >postgis.refractions.net/mailman/listinfo/postgis-devel
<br>>> >
<br>>> >
<br>> _______________________________________________
<br>> postgis-devel mailing list
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26462234&i=2" target="_top" rel="nofollow">postgis-devel@...</a>
<br>> <a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_top" rel="nofollow">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br>>
<br>>
</div>_______________________________________________
<br>postgis-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26462234&i=3" target="_top" rel="nofollow">postgis-devel@...</a>
<br><a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_top" rel="nofollow">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br><p>From forum: <a href="http://old.nabble.com/PostGIS---Dev-f1222.html" embed="fixTarget[1222]" target="_top" >PostGIS - Dev</a></p>tag:old.nabble.com,2006:post-26462173Re: Distance patch2009-11-21T17:46:51Z2009-11-21T17:46:51ZNicklas Avén<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>Now I have committed something for the empty geometries.
<div align="left"> </div>
<div align="left">Please take a look</div>
<div align="left"> </div>
<div align="left">I use MAXFLOAT as startvalue when seeking mindistance. Is that ok?</div>
<div align="left">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?</div>
<div align="left"> </div>
<div align="left">I also check so no empty geometries will go into the calculations but just be returned and not touching mindistance.</div>
<div align="left"> </div>
<div align="left">st_distance, st_dwithin are now supposed to return according to the empty geometry document.</div>
<div align="left">st_max_distance and st_dfyllywithin should behave the same way as their corresponding above.</div>
<div align="left">st_shortestline, st_closestpoint and st_longestline should return null</div>
<div align="left"> </div>
<div align="left">/Nicklas</div>
<div align="left"> </div>
<div align="left"><br />
<br />
2009-11-21 Nicklas Avén wrote:<br />
<br />
></div>
<div align="left">Sounds great</div>>
<div align="left"> </div>>
<div align="left">I'm working on the empty geometry handling. Didn't have time earlier today but should be done in some hours.</div>>
<div align="left"> </div>>
<div align="left">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.</div>>
<div align="left"> </div>>
<div align="left">Thanks</div>>
<div align="left">Nicklas</div>>
<div align="left"> </div>>
<div align="left"><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 to<br />
> >go in.<br />
> ><br />
> >Nicklas -- your subgeom change fixed the anomalies I started to notice (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 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) 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 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 and<br />
> >No.<br />
> ><br />
> >The person in me that just wants a single feature (say faster dist or 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 />
> ><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26462173&i=0" target="_top" rel="nofollow">postgis-devel@...</a><br />
> >postgis.refractions.net/mailman/listinfo/postgis-devel<br />
> ><br />
> ></div>
</body>
</html>
<br />_______________________________________________
<br>postgis-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26462173&i=1" target="_top" rel="nofollow">postgis-devel@...</a>
<br><a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_top" rel="nofollow">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br><p>From forum: <a href="http://old.nabble.com/PostGIS---Dev-f1222.html" embed="fixTarget[1222]" target="_top" >PostGIS - Dev</a></p>tag:old.nabble.com,2006:post-26462129IRC2009-11-21T17:35:35Z2009-11-21T17:35:35ZPaul Ramsey-4BTW, IRC is always open for techtalk: irc://irc.freenode.net/postgis (Nick!)
<br><br>P
<br>_______________________________________________
<br>postgis-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26462129&i=0" target="_top" rel="nofollow">postgis-devel@...</a>
<br><a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_top" rel="nofollow">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br><p>From forum: <a href="http://old.nabble.com/PostGIS---Dev-f1222.html" embed="fixTarget[1222]" target="_top" >PostGIS - Dev</a></p>tag:old.nabble.com,2006:post-26461872Re: short question2009-11-21T16:42:00Z2009-11-21T16:42:00ZPaul Ramsey-3I don't think you should be returning EMPTY in any of your functions,
<br>I think NULL is a reasonable return value for
<br>st_shortestline(empty,empty).
<br><br>P
<br><br>On Sat, Nov 21, 2009 at 4:32 PM, Nicklas Avén
<br><<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26461872&i=0" target="_top" rel="nofollow">nicklas.aven@...</a>> wrote:
<div class='shrinkable-quote'><br>> My first post was just about how to move the information internally that an
<br>> empty geometry should be returned, from my function lw_dist2d_distanceline
<br>> in measures.c to function LWGEOM_shortestline2d in lwgeom_functions_basic,
<br>> when the expected return is LWLINE
<br>>
<br>> But I have realised that the thing is a little bit bigger because I out to
<br>> return the right type externally too.
<br>> Otherwise it will violate constraints if people tries to put the result in a
<br>> table.
<br>>
<br>> Is this solved in other functions like st_union or st_difference?
<br>>
<br>> /Nicklas
<br>>
<br>>
<br>>
<br>> 2009-11-22 Paul Ramsey wrote:
<br>>
<br>> You are constructing empty geometries? Why? (Or is this a question of
<br>>>curiosity?)
<br>>>
<br>> >From an API PoV we should probably make some functions to do this, but
<br>>>the details are, generally, an LWGEOM with a POINTARRAY that has
<br>>>npoints = 0. Or, for collections, a collection with ngeoms = 0. I
<br>>>believe I also consider LWGEOMs with a null POINTARRAY or a null
<br>>>**geoms to be empty, but I'd have to confirm. The exact way of
<br>>>representing empty things was never fully documented
<br>>>
<br>>>P.
<br>>>
<br>>>On Sat, Nov 21, 2009 at 4:13 PM, Nicklas Avén
<br>>> wrote:
<br>>>> OK
<br>>>>
<br>>>> But what to send as empty when LWLINE or LWPOINT is wanted, not
<br>>>> LWCOLLECTION.
<br>>>> internally I mean.
<br>>>> /Nicklas
<br>>>>
<br>>>> 2009-11-22 Paul Ramsey wrote:
<br>>>>
<br>>>> No, bad idea. Empty geometries have a type. There's 'POLYGON EMPTY',
<br>>>>>'LINESTRING EMPTY', etc, etc, etc.
<br>>>>>
<br>>>>>P.
<br>>>>>
<br>>>>>On Sat, Nov 21, 2009 at 2:04 PM, Nicklas Avén
<br>>>>> wrote:
<br>>>>>> is type 0 for LWGEOM occupied by anything or could it be an idea to use
<br>>>>>> it
<br>>>>>> for empty geometries.
<br>>>>>> Then it would be easy to create any emtpy geometry. Like a generic
<br>>>>>> empty
<br>>>>>> geometry.
<br>>>>>>
<br>>>>>> Or is there another way that I have missed.
<br>>>>>>
<br>>>>>> When I have identified the empty geometries, in shortestline and it
<br>>>>>> buddies
<br>>>>>> I need to communicate that an empty geometry should be returned and the
<br>>>>>> datatype is LWLINE and LWPOINT for st_closestpoint. I'm tempted to just
<br>>>>>> make
<br>>>>>> an LWGEOM with type 0. Is it a bad idea.
<br>>>>>>
<br>>>>>> #define EMPTY 0
<br>>>>>> #define POINTTYPE 1
<br>>>>>> #define LINETYPE 2
<br>>>>>> #define POLYGONTYPE 3
<br>>>>>> and so on
<br>>>>>>
<br>>>>>> /Nicklas
<br>>>>>> _______________________________________________
<br>>>>>> postgis-devel mailing list
<br>>>>>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26461872&i=1" target="_top" rel="nofollow">postgis-devel@...</a>
<br>>>>>> <a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_top" rel="nofollow">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br>>>>>>
<br>>>>>>
<br>>>>>_______________________________________________
<br>>>>>postgis-devel mailing list
<br>>>>><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26461872&i=2" target="_top" rel="nofollow">postgis-devel@...</a>
<br>>>>><a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_top" rel="nofollow">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br>>>>>
<br>>>>>
<br>>>> _______________________________________________
<br>>>> postgis-devel mailing list
<br>>>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26461872&i=3" target="_top" rel="nofollow">postgis-devel@...</a>
<br>>>> <a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_top" rel="nofollow">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br>>>>
<br>>>>
<br>>>_______________________________________________
<br>>>postgis-devel mailing list
<br>>><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26461872&i=4" target="_top" rel="nofollow">postgis-devel@...</a>
<br>>><a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_top" rel="nofollow">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br>>>
<br>>>
<br>> _______________________________________________
<br>> postgis-devel mailing list
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26461872&i=5" target="_top" rel="nofollow">postgis-devel@...</a>
<br>> <a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_top" rel="nofollow">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br>>
<br>>
</div>_______________________________________________
<br>postgis-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26461872&i=6" target="_top" rel="nofollow">postgis-devel@...</a>
<br><a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_top" rel="nofollow">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br><p>From forum: <a href="http://old.nabble.com/PostGIS---Dev-f1222.html" embed="fixTarget[1222]" target="_top" >PostGIS - Dev</a></p>tag:old.nabble.com,2006:post-26461822Re: short question2009-11-21T16:32:04Z2009-11-21T16:32:04ZNicklas Avén<html>
<head>
<title></title>
<meta name="GENERATOR" content="MSHTML 8.00.6001.18852"></meta>
<meta name="SKYPE_FRAMEID" content="UKSDOXEVME"></meta>
<meta id="skype_v3_tb_marker_id" name="SKYPE_PARSING_HAS_FINISHED" content="metacontent"></meta>
</head>
<body>
<div align="left">My first post was just about how to move the information internally that an empty geometry should be returned, from my function lw_dist2d_distanceline in measures.c to function LWGEOM_shortestline2d in lwgeom_functions_basic, when the expected return is LWLINE</div>
<div align="left"> </div>
<div align="left">But I have realised that the thing is a little bit bigger because I out to return the right type externally too.</div>
<div align="left">Otherwise it will violate constraints if people tries to put the result in a table.</div>
<div align="left"> </div>
<div align="left">Is this solved in other functions like st_union or st_difference?</div>
<div align="left"> </div>
<div align="left">/Nicklas</div>
<div align="left"> </div>
<div align="left"> </div>
<div align="left"><br />
<br />
2009-11-22 Paul Ramsey wrote:<br />
<br />
You are constructing empty geometries? Why? (Or is this a question of<br />
>curiosity?)<br />
><br />
>From an API PoV we should probably make some functions to do this, but<br />
>the details are, generally, an LWGEOM with a POINTARRAY that has<br />
>npoints = 0. Or, for collections, a collection with ngeoms = 0. I<br />
>believe I also consider LWGEOMs with a null POINTARRAY or a null<br />
>**geoms to be empty, but I'd have to confirm. The exact way of<br />
>representing empty things was never fully documented<br />
><br />
>P.<br />
><br />
>On Sat, Nov 21, 2009 at 4:13 PM, Nicklas Avén<br />
>
<nicklas.aven@jordogskog.no></nicklas.aven@jordogskog.no> wrote:<br />
>> OK<br />
>><br />
>> But what to send as empty when LWLINE or LWPOINT is wanted, not<br />
>> LWCOLLECTION.<br />
>> internally I mean.<br />
>> /Nicklas<br />
>><br />
>> 2009-11-22 Paul Ramsey wrote:<br />
>><br />
>> No, bad idea. Empty geometries have a type. There's 'POLYGON EMPTY',<br />
>>>'LINESTRING EMPTY', etc, etc, etc.<br />
>>><br />
>>>P.<br />
>>><br />
>>>On Sat, Nov 21, 2009 at 2:04 PM, Nicklas Avén<br />
>>> wrote:<br />
>>>> is type 0 for LWGEOM occupied by anything or could it be an idea to use<br />
>>>> it<br />
>>>> for empty geometries.<br />
>>>> Then it would be easy to create any emtpy geometry. Like a generic empty<br />
>>>> geometry.<br />
>>>><br />
>>>> Or is there another way that I have missed.<br />
>>>><br />
>>>> When I have identified the empty geometries, in shortestline and it<br />
>>>> buddies<br />
>>>> I need to communicate that an empty geometry should be returned and the<br />
>>>> datatype is LWLINE and LWPOINT for st_closestpoint. I'm tempted to just<br />
>>>> make<br />
>>>> an LWGEOM with type 0. Is it a bad idea.<br />
>>>><br />
>>>> #define EMPTY 0<br />
>>>> #define POINTTYPE 1<br />
>>>> #define LINETYPE 2<br />
>>>> #define POLYGONTYPE 3<br />
>>>> and so on<br />
>>>><br />
>>>> /Nicklas<br />
>>>> _______________________________________________<br />
>>>> postgis-devel mailing list<br />
>>>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26461822&i=0" target="_top" rel="nofollow">postgis-devel@...</a><br />
>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel<br />
>>>><br />
>>>><br />
>>>_______________________________________________<br />
>>>postgis-devel mailing list<br />
>>><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26461822&i=1" target="_top" rel="nofollow">postgis-devel@...</a><br />
>>>http://postgis.refractions.net/mailman/listinfo/postgis-devel<br />
>>><br />
>>><br />
>> _______________________________________________<br />
>> postgis-devel mailing list<br />
>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26461822&i=2" target="_top" rel="nofollow">postgis-devel@...</a><br />
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel<br />
>><br />
>><br />
>_______________________________________________<br />
>postgis-devel mailing list<br />
><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26461822&i=3" target="_top" rel="nofollow">postgis-devel@...</a><br />
>http://postgis.refractions.net/mailman/listinfo/postgis-devel<br />
><br />
></div>
</body>
</html>
<br />_______________________________________________
<br>postgis-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26461822&i=4" target="_top" rel="nofollow">postgis-devel@...</a>
<br><a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_top" rel="nofollow">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br><p>From forum: <a href="http://old.nabble.com/PostGIS---Dev-f1222.html" embed="fixTarget[1222]" target="_top" >PostGIS - Dev</a></p>tag:old.nabble.com,2006:post-26461724Re: short question2009-11-21T16:16:40Z2009-11-21T16:16:40ZPaul Ramsey-3You are constructing empty geometries? Why? (Or is this a question of
<br>curiosity?)
<br><br>From an API PoV we should probably make some functions to do this, but
<br>the details are, generally, an LWGEOM with a POINTARRAY that has
<br>npoints = 0. Or, for collections, a collection with ngeoms = 0. I
<br>believe I also consider LWGEOMs with a null POINTARRAY or a null
<br>**geoms to be empty, but I'd have to confirm. The exact way of
<br>representing empty things was never fully documented
<br><br>P.
<br><br>On Sat, Nov 21, 2009 at 4:13 PM, Nicklas Avén
<br><<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26461724&i=0" target="_top" rel="nofollow">nicklas.aven@...</a>> wrote:
<div class='shrinkable-quote'><br>> OK
<br>>
<br>> But what to send as empty when LWLINE or LWPOINT is wanted, not
<br>> LWCOLLECTION.
<br>> internally I mean.
<br>> /Nicklas
<br>>
<br>> 2009-11-22 Paul Ramsey wrote:
<br>>
<br>> No, bad idea. Empty geometries have a type. There's 'POLYGON EMPTY',
<br>>>'LINESTRING EMPTY', etc, etc, etc.
<br>>>
<br>>>P.
<br>>>
<br>>>On Sat, Nov 21, 2009 at 2:04 PM, Nicklas Avén
<br>>> wrote:
<br>>>> is type 0 for LWGEOM occupied by anything or could it be an idea to use
<br>>>> it
<br>>>> for empty geometries.
<br>>>> Then it would be easy to create any emtpy geometry. Like a generic empty
<br>>>> geometry.
<br>>>>
<br>>>> Or is there another way that I have missed.
<br>>>>
<br>>>> When I have identified the empty geometries, in shortestline and it
<br>>>> buddies
<br>>>> I need to communicate that an empty geometry should be returned and the
<br>>>> datatype is LWLINE and LWPOINT for st_closestpoint. I'm tempted to just
<br>>>> make
<br>>>> an LWGEOM with type 0. Is it a bad idea.
<br>>>>
<br>>>> #define EMPTY 0
<br>>>> #define POINTTYPE 1
<br>>>> #define LINETYPE 2
<br>>>> #define POLYGONTYPE 3
<br>>>> and so on
<br>>>>
<br>>>> /Nicklas
<br>>>> _______________________________________________
<br>>>> postgis-devel mailing list
<br>>>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26461724&i=1" target="_top" rel="nofollow">postgis-devel@...</a>
<br>>>> <a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_top" rel="nofollow">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br>>>>
<br>>>>
<br>>>_______________________________________________
<br>>>postgis-devel mailing list
<br>>><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26461724&i=2" target="_top" rel="nofollow">postgis-devel@...</a>
<br>>><a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_top" rel="nofollow">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br>>>
<br>>>
<br>> _______________________________________________
<br>> postgis-devel mailing list
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26461724&i=3" target="_top" rel="nofollow">postgis-devel@...</a>
<br>> <a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_top" rel="nofollow">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br>>
<br>>
</div>_______________________________________________
<br>postgis-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26461724&i=4" target="_top" rel="nofollow">postgis-devel@...</a>
<br><a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_top" rel="nofollow">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br><p>From forum: <a href="http://old.nabble.com/PostGIS---Dev-f1222.html" embed="fixTarget[1222]" target="_top" >PostGIS - Dev</a></p>tag:old.nabble.com,2006:post-26461709Re: short question2009-11-21T16:13:17Z2009-11-21T16:13:17ZNicklas Avén<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>OK
<div align="left"> </div>
<div align="left">But what to send as empty when LWLINE or LWPOINT is wanted, not LWCOLLECTION.</div>
<div align="left">internally I mean. </div>
<div align="left">/Nicklas<br />
<br />
2009-11-22 Paul Ramsey wrote:<br />
<br />
No, bad idea. Empty geometries have a type. There's 'POLYGON EMPTY',<br />
>'LINESTRING EMPTY', etc, etc, etc.<br />
><br />
>P.<br />
><br />
>On Sat, Nov 21, 2009 at 2:04 PM, Nicklas Avén<br />
>
<nicklas.aven@jordogskog.no></nicklas.aven@jordogskog.no> wrote:<br />
>> is type 0 for LWGEOM occupied by anything or could it be an idea to use it<br />
>> for empty geometries.<br />
>> Then it would be easy to create any emtpy geometry. Like a generic empty<br />
>> geometry.<br />
>><br />
>> Or is there another way that I have missed.<br />
>><br />
>> When I have identified the empty geometries, in shortestline and it buddies<br />
>> I need to communicate that an empty geometry should be returned and the<br />
>> datatype is LWLINE and LWPOINT for st_closestpoint. I'm tempted to just make<br />
>> an LWGEOM with type 0. Is it a bad idea.<br />
>><br />
>> #define EMPTY 0<br />
>> #define POINTTYPE 1<br />
>> #define LINETYPE 2<br />
>> #define POLYGONTYPE 3<br />
>> and so on<br />
>><br />
>> /Nicklas<br />
>> _______________________________________________<br />
>> postgis-devel mailing list<br />
>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26461709&i=0" target="_top" rel="nofollow">postgis-devel@...</a><br />
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel<br />
>><br />
>><br />
>_______________________________________________<br />
>postgis-devel mailing list<br />
><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26461709&i=1" target="_top" rel="nofollow">postgis-devel@...</a><br />
>http://postgis.refractions.net/mailman/listinfo/postgis-devel<br />
><br />
></div>
</body>
</html>
<br />_______________________________________________
<br>postgis-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26461709&i=2" target="_top" rel="nofollow">postgis-devel@...</a>
<br><a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_top" rel="nofollow">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br><p>From forum: <a href="http://old.nabble.com/PostGIS---Dev-f1222.html" embed="fixTarget[1222]" target="_top" >PostGIS - Dev</a></p>tag:old.nabble.com,2006:post-26461688Re: short question2009-11-21T16:08:22Z2009-11-21T16:08:22ZPaul Ramsey-3No, bad idea. Empty geometries have a type. There's 'POLYGON EMPTY',
<br>'LINESTRING EMPTY', etc, etc, etc.
<br><br>P.
<br><br>On Sat, Nov 21, 2009 at 2:04 PM, Nicklas Avén
<br><<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26461688&i=0" target="_top" rel="nofollow">nicklas.aven@...</a>> wrote:
<div class='shrinkable-quote'><br>> is type 0 for LWGEOM occupied by anything or could it be an idea to use it
<br>> for empty geometries.
<br>> Then it would be easy to create any emtpy geometry. Like a generic empty
<br>> geometry.
<br>>
<br>> Or is there another way that I have missed.
<br>>
<br>> When I have identified the empty geometries, in shortestline and it buddies
<br>> I need to communicate that an empty geometry should be returned and the
<br>> datatype is LWLINE and LWPOINT for st_closestpoint. I'm tempted to just make
<br>> an LWGEOM with type 0. Is it a bad idea.
<br>>
<br>> #define EMPTY 0
<br>> #define POINTTYPE 1
<br>> #define LINETYPE 2
<br>> #define POLYGONTYPE 3
<br>> and so on
<br>>
<br>> /Nicklas
<br>> _______________________________________________
<br>> postgis-devel mailing list
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26461688&i=1" target="_top" rel="nofollow">postgis-devel@...</a>
<br>> <a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_top" rel="nofollow">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br>>
<br>>
</div>_______________________________________________
<br>postgis-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26461688&i=2" target="_top" rel="nofollow">postgis-devel@...</a>
<br><a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_top" rel="nofollow">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br><p>From forum: <a href="http://old.nabble.com/PostGIS---Dev-f1222.html" embed="fixTarget[1222]" target="_top" >PostGIS - Dev</a></p>tag:old.nabble.com,2006:post-26460783short question2009-11-21T14:04:18Z2009-11-21T14:04:18ZNicklas Avén<html>
<head>
<title></title>
<meta name="GENERATOR" content="MSHTML 8.00.6001.18852"></meta>
<meta name="SKYPE_FRAMEID" content="WAXKGQBHBH"></meta>
<meta id="skype_v3_tb_marker_id" name="SKYPE_PARSING_HAS_FINISHED" content="metacontent"></meta>
</head>
<body>
<div>is type 0 for LWGEOM occupied by anything or could it be an idea to use it for empty geometries. </div>
<div>Then it would be easy to create any emtpy geometry. Like a generic empty geometry.</div>
<div> </div>
<div>Or is there another way that I have missed.</div>
<div> </div>
<div>When I have identified the empty geometries, in shortestline and it buddies I need to communicate that an empty geometry should be returned and the datatype is LWLINE and LWPOINT for st_closestpoint. I'm tempted to just make an LWGEOM with type 0. Is it a bad idea. </div>
<div> </div>
<div>#define EMPTY 0</div>
<div>#define POINTTYPE 1<br />
#define LINETYPE 2<br />
#define POLYGONTYPE 3</div>
<div>and so on</div>
<div> </div>
<div>/Nicklas</div>
</body>
</html>
<br />_______________________________________________
<br>postgis-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26460783&i=0" target="_top" rel="nofollow">postgis-devel@...</a>
<br><a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_top" rel="nofollow">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br><p>From forum: <a href="http://old.nabble.com/PostGIS---Dev-f1222.html" embed="fixTarget[1222]" target="_top" >PostGIS - Dev</a></p>tag:old.nabble.com,2006:post-26459349Re: Distance patch2009-11-21T11:03:39Z2009-11-21T11:03:39ZNicklas Avén<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">Sounds great</div>
<div align="left"> </div>
<div align="left">I'm working on the empty geometry handling. Didn't have time earlier today but should be done in some hours.</div>
<div align="left"> </div>
<div align="left">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.</div>
<div align="left"> </div>
<div align="left">Thanks</div>
<div align="left">Nicklas</div>
<div align="left"> </div>
<div align="left"><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 to<br />
>go in.<br />
><br />
>Nicklas -- your subgeom change fixed the anomalies I started to notice (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 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) 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 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 and<br />
>No.<br />
><br />
>The person in me that just wants a single feature (say faster dist or 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 />
><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26459349&i=0" target="_top" rel="nofollow">postgis-devel@...</a><br />
>http://postgis.refractions.net/mailman/listinfo/postgis-devel<br />
><br />
></div>
</body>
</html>
<br />_______________________________________________
<br>postgis-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26459349&i=1" target="_top" rel="nofollow">postgis-devel@...</a>
<br><a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_top" rel="nofollow">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br><p>From forum: <a href="http://old.nabble.com/PostGIS---Dev-f1222.html" embed="fixTarget[1222]" target="_top" >PostGIS - Dev</a></p>tag:old.nabble.com,2006:post-26459280Distance ST_DWithin2009-11-21T10:54:39Z2009-11-21T10:54:39ZParagon Corporation-2Forgot to add -- I did test ST_Dwithin as well. I wasn't so much concerned
<br>about speed as to make sure counts were the same. So I pulled some queries
<br>from my log files and tested with the old and new to verify the counts of
<br>records returned the same and they did.
<br><br>I'll try to put together a test suite that doesn't require data, but it will
<br>be easier to do once the patch is in so I don't have to forgoet which
<br>postgis-1.5 I'm currently running.
<br><br>Thanks,
<br>Regina
<br><br><br>_______________________________________________
<br>postgis-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26459280&i=0" target="_top" rel="nofollow">postgis-devel@...</a>
<br><a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_top" rel="nofollow">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br><p>From forum: <a href="http://old.nabble.com/PostGIS---Dev-f1222.html" embed="fixTarget[1222]" target="_top" >PostGIS - Dev</a></p>tag:old.nabble.com,2006:post-26459231Re: Distance patch2009-11-21T10:49:43Z2009-11-21T10:49:43ZPaul Ramsey-3Mark, if you're going to do a review, let me know, otherwise I'm going
<br>to proceed with the integration early this week.
<br><br>P
<br><br>On Sat, Nov 21, 2009 at 10:43 AM, Paragon Corporation <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26459231&i=0" target="_top" rel="nofollow">lr@...</a>> wrote:
<div class='shrinkable-quote'><br>> Paul and Nicklas,
<br>> The patch looks good to me. So if Nicklas is ready I would say its good to
<br>> go in.
<br>>
<br>> Nicklas -- your subgeom change fixed the anomalies I started to notice (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 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) 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 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 and
<br>> No.
<br>>
<br>> The person in me that just wants a single feature (say faster dist or 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>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26459231&i=1" target="_top" rel="nofollow">postgis-devel@...</a>
<br>> <a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_top" rel="nofollow">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br>>
</div>_______________________________________________
<br>postgis-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26459231&i=2" target="_top" rel="nofollow">postgis-devel@...</a>
<br><a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_top" rel="nofollow">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br><p>From forum: <a href="http://old.nabble.com/PostGIS---Dev-f1222.html" embed="fixTarget[1222]" target="_top" >PostGIS - Dev</a></p>tag:old.nabble.com,2006:post-26459186Distance patch2009-11-21T10:43:59Z2009-11-21T10:43:59ZParagon Corporation-2Paul and Nicklas,
<br>The patch looks good to me. So if Nicklas is ready I would say its good to
<br>go in.
<br><br>Nicklas -- your subgeom change fixed the anomalies I started to notice (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 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) 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 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 and
<br>No.
<br><br>The person in me that just wants a single feature (say faster dist or 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><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26459186&i=0" target="_top" rel="nofollow">postgis-devel@...</a>
<br><a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_top" rel="nofollow">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br><p>From forum: <a href="http://old.nabble.com/PostGIS---Dev-f1222.html" embed="fixTarget[1222]" target="_top" >PostGIS - Dev</a></p>tag:old.nabble.com,2006:post-26459091Re: [PostGIS] #315: Entity postgis_aggs_mm not defined2009-11-21T10:30:39Z2009-11-21T10:30:39ZPostGIS-4#315: Entity postgis_aggs_mm not defined
<br>----------------------+-----------------------------------------------------
<br> Reporter: mloskot | Owner: colivier
<br> Type: defect | Status: closed
<br> Priority: medium | Milestone: PostGIS 1.5.0
<br> Component: postgis | Version: trunk
<br>Resolution: fixed | Keywords:
<br>----------------------+-----------------------------------------------------
<br>Changes (by pramsey):
<br><br> * status: new => closed
<br> * resolution: => fixed
<br><br>--
<br>Ticket URL: <<a href="http://trac.osgeo.org/postgis/ticket/315#comment:7" target="_top" rel="nofollow">http://trac.osgeo.org/postgis/ticket/315#comment:7</a>>
<br>PostGIS <<a href="http://trac.osgeo.org/postgis/" target="_top" rel="nofollow">http://trac.osgeo.org/postgis/</a>>
<br>The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
<br>_______________________________________________
<br>postgis-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26459091&i=0" target="_top" rel="nofollow">postgis-devel@...</a>
<br><a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_top" rel="nofollow">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br><p>From forum: <a href="http://old.nabble.com/PostGIS---Dev-f1222.html" embed="fixTarget[1222]" target="_top" >PostGIS - Dev</a></p>tag:old.nabble.com,2006:post-26458681Re: [PostGIS] #315: Entity postgis_aggs_mm not defined2009-11-21T09:46:20Z2009-11-21T09:46:20ZPostGIS-4#315: Entity postgis_aggs_mm not defined
<br>----------------------+-----------------------------------------------------
<br> Reporter: mloskot | Owner: colivier
<br> Type: defect | Status: new
<br> Priority: medium | Milestone: PostGIS 1.5.0
<br> Component: postgis | Version: trunk
<br>Resolution: | Keywords:
<br>----------------------+-----------------------------------------------------
<br>Comment (by mloskot):
<br><br> Kevin, I've tested and I can confirm it's fixed for me. Thank you!
<br><br>--
<br>Ticket URL: <<a href="http://trac.osgeo.org/postgis/ticket/315#comment:6" target="_top" rel="nofollow">http://trac.osgeo.org/postgis/ticket/315#comment:6</a>>
<br>PostGIS <<a href="http://trac.osgeo.org/postgis/" target="_top" rel="nofollow">http://trac.osgeo.org/postgis/</a>>
<br>The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
<br>_______________________________________________
<br>postgis-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26458681&i=0" target="_top" rel="nofollow">postgis-devel@...</a>
<br><a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_top" rel="nofollow">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br><p>From forum: <a href="http://old.nabble.com/PostGIS---Dev-f1222.html" embed="fixTarget[1222]" target="_top" >PostGIS - Dev</a></p>tag:old.nabble.com,2006:post-26452468Re: Distance Merge2009-11-20T16:32:02Z2009-11-20T16:32:02ZPaul Ramsey-3On Fri, Nov 20, 2009 at 1:51 PM, Nicklas Avén
<br><<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26452468&i=0" target="_top" rel="nofollow">nicklas.aven@...</a>> wrote:
<br>> what is not fixed is handling the empty geometries.
<br><br>Detect with lwgeom_is_empty()
<br><br>> I would like some suggestion or advice.
<br>> I have looked a little at the old code. It seems to return 0 at once there
<br>> is one empty geometry in a collection. Is that right behavior? or is it the
<br>> parser that defines this anyway?
<br><br>The right behavior is defined here:
<br><br><a href="http://trac.osgeo.org/postgis/wiki/DevWikiEmptyGeometry" target="_top" rel="nofollow">http://trac.osgeo.org/postgis/wiki/DevWikiEmptyGeometry</a><br><br>I am going to update that page a bit to reflect your question on
<br>collections -- if any part of the collection is non-empty, the
<br>distance is defined against that part. If it is all empty, the
<br>distance is NULL.
<br><br>P.
<br><div class='shrinkable-quote'><br>>
<br>> otherwise I think we can put it in trunk. If any bugs show I think they will
<br>> be quite easy to find.
<br>> If not Regina has seen any unstabilities?
<br>>
<br>> Thanks
<br>> Nicklas
<br>>
<br>> 2009-11-20 Paul Ramsey wrote:
<br>>
<br>> Nicklas, do you feel like your distance work is ready to merge?
<br>>>
<br>>>P
<br>>>_______________________________________________
<br>>>postgis-devel mailing list
<br>>><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26452468&i=1" target="_top" rel="nofollow">postgis-devel@...</a>
<br>>><a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_top" rel="nofollow">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br>>>
<br>>>
<br>> _______________________________________________
<br>> postgis-devel mailing list
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26452468&i=2" target="_top" rel="nofollow">postgis-devel@...</a>
<br>> <a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_top" rel="nofollow">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br>>
<br>>
</div>_______________________________________________
<br>postgis-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26452468&i=3" target="_top" rel="nofollow">postgis-devel@...</a>
<br><a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_top" rel="nofollow">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br><p>From forum: <a href="http://old.nabble.com/PostGIS---Dev-f1222.html" embed="fixTarget[1222]" target="_top" >PostGIS - Dev</a></p>tag:old.nabble.com,2006:post-26450859Re: Distance Merge2009-11-20T13:51:54Z2009-11-20T13:51:54ZNicklas Avén<html>
<head>
<title></title>
<meta name="GENERATOR" content="MSHTML 8.00.6001.18852"></meta>
<meta name="SKYPE_FRAMEID" content="UKSDOXEVME"></meta>
<meta id="skype_v3_tb_marker_id" name="SKYPE_PARSING_HAS_FINISHED" content="metacontent"></meta>
</head>
<body>
<div>what is not fixed is handling the empty geometries.</div>
<div>I would like some suggestion or advice. </div>
<div>I have looked a little at the old code. It seems to return 0 at once there is one empty geometry in a collection. Is that right behavior? or is it the parser that defines this anyway?</div>
<div> </div>
<div>otherwise I think we can put it in trunk. If any bugs show I think they will be quite easy to find. </div>
<div>If not Regina has seen any unstabilities?</div>
<div> </div>
<div>Thanks</div>
<div>Nicklas</div>
<div> </div>
<div>2009-11-20 Paul Ramsey wrote:<br />
<br />
Nicklas, do you feel like your distance work is ready to merge?<br />
><br />
>P<br />
>_______________________________________________<br />
>postgis-devel mailing list<br />
><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26450859&i=0" target="_top" rel="nofollow">postgis-devel@...</a><br />
>http://postgis.refractions.net/mailman/listinfo/postgis-devel<br />
><br />
></div>
</body>
</html>
<br />_______________________________________________
<br>postgis-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26450859&i=1" target="_top" rel="nofollow">postgis-devel@...</a>
<br><a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_top" rel="nofollow">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br><p>From forum: <a href="http://old.nabble.com/PostGIS---Dev-f1222.html" embed="fixTarget[1222]" target="_top" >PostGIS - Dev</a></p>tag:old.nabble.com,2006:post-26449715Re: [PostGIS] #316: IsValid called on invalid 3d object leads to crash2009-11-20T12:23:20Z2009-11-20T12:23:20ZPostGIS-4#316: IsValid called on invalid 3d object leads to crash
<br>----------------------+-----------------------------------------------------
<br> Reporter: pramsey | Owner: pramsey
<br> Type: defect | Status: new
<br> Priority: medium | Milestone: PostGIS 1.5.0
<br> Component: postgis | Version: trunk
<br>Resolution: | Keywords:
<br>----------------------+-----------------------------------------------------
<br>Comment (by pramsey):
<br><br> I can make it crash differently by adding a redundant point (and thereby
<br> passing through the minpoints test).
<br> {{{
<br> select 'POLYGON ((-97.78351581 36.37358796 1167.172,-97.78303556
<br> 36.37319923 1167.172,-97.78303556 36.37319923 1167.172,-98.88351581
<br> 38.37358796 1167.172))'::geometry;
<br> }}}
<br><br>--
<br>Ticket URL: <<a href="http://trac.osgeo.org/postgis/ticket/316#comment:2" target="_top" rel="nofollow">http://trac.osgeo.org/postgis/ticket/316#comment:2</a>>
<br>PostGIS <<a href="http://trac.osgeo.org/postgis/" target="_top" rel="nofollow">http://trac.osgeo.org/postgis/</a>>
<br>The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
<br>_______________________________________________
<br>postgis-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26449715&i=0" target="_top" rel="nofollow">postgis-devel@...</a>
<br><a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_top" rel="nofollow">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br><p>From forum: <a href="http://old.nabble.com/PostGIS---Dev-f1222.html" embed="fixTarget[1222]" target="_top" >PostGIS - Dev</a></p>tag:old.nabble.com,2006:post-26449208Re: The Road to 1.52009-11-20T11:43:15Z2009-11-20T11:43:15ZPaul Ramsey-4It's not a platform thing, I'm building on OS/X and having no
<br>problems. Probably this "pkgsrc postgresql" of which you speak, which
<br>I am not familiar with.
<br><br>P.
<br><br>On Fri, Nov 20, 2009 at 11:34 AM, Greg Troxel <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26449208&i=0" target="_top" rel="nofollow">gdt@...</a>> wrote:
<div class='shrinkable-quote'><br>>
<br>> Hi Folks, as you can tell, I'm really jonesing to get a 1.5 release
<br>> out, but the ticket list is increasingly not mine.
<br>>
<br>> The build failed for me under mac os x 10.5.8, with pkgsrc postgresql.
<br>> Should I be filing a ticket about this? Has anyone else built on a mac?
<br>> Is that a platform the failure of which should be considered a bug?
<br>>
<br>> _______________________________________________
<br>> postgis-devel mailing list
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26449208&i=1" target="_top" rel="nofollow">postgis-devel@...</a>
<br>> <a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_top" rel="nofollow">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br>>
<br>>
</div>_______________________________________________
<br>postgis-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26449208&i=2" target="_top" rel="nofollow">postgis-devel@...</a>
<br><a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_top" rel="nofollow">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br><p>From forum: <a href="http://old.nabble.com/PostGIS---Dev-f1222.html" embed="fixTarget[1222]" target="_top" >PostGIS - Dev</a></p>