<div dir="ltr"><div>No problem,<br></div>for perf sake you should take a look at the "quad_segs" buffer option, you probably can trade an increase of radius to 0.002 versus a number of quad_segs of 2.<br>Cheers,<br>
Rémi-C<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-05-23 15:58 GMT+02:00 Jeff Adams - NOAA Affiliate <span dir="ltr"><<a href="mailto:jeff.adams@noaa.gov" target="_blank">jeff.adams@noaa.gov</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks again Remi-C. I have been playing around with the buffer function. I ended up clipping with the original boundary and then "pushed" the polygon boundary out 0.001 meter using the st_buffer function before running the st_within function. Seemed to do the trick, crossing my fingers that I do not have any split geometries that originated 0.001 meters outside of the polygon!<br>
</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 23, 2014 at 9:41 AM, Rémi Cura <span dir="ltr"><<a href="mailto:remi.cura@gmail.com" target="_blank">remi.cura@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>The idea is ST_Within(A,B) is true if no point (mathematical sense) of A is outside of B.<br>
<br></div>Now, when splitting a line with another one (the boundary of the polygon in your case), postgis creates a point just on the boundary of this polygon to end the line.<br>
</div>The problem is, this point could be in either side of the line depending of the rounding error of the computing.<br><br></div>It is not "reported" because it is the limit of the current postGis approach regarding numerical precision.<br>
<br><div>The solution either involve enforcing the knowledge you have of what you want<br></div><div>(for instance, force the point that was created by the split to be on the boundary of the polygon)<br></div><div>or use error threshold (effectively becoming fuzzy predicates).<br>
</div><div><br>In your case and if you want fast processing, you could change your predicate to avoid using ST_Within but rather predicates involving a threshold like ST_Dwithin.<br></div><div>Here you could use ST_Max_Distance to filter out outside geometries.<br>
<br></div><div>Now if you really want correct answer I'm affraid you would have to use the buffer function (example : bufferize your lines with tha amount of uncertainity on your data and compute the shared area with the polygon. If the shared area is big relatovely to the buffer area, you are inside, else you are outside.<br>
)<br><br><br></div><div>A more pragmatic approach would be to cut your lines not with the polygon but with a buffer of the boundary of the polygon, so that your cut lines a clearly inside or outside the polygons.<br><br>
</div>
<div>Cheers;<br>Rémi-C<br></div><div><br><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-05-23 14:28 GMT+02:00 Jeff Adams - NOAA Affiliate <span dir="ltr"><<a href="mailto:jeff.adams@noaa.gov" target="_blank">jeff.adams@noaa.gov</a>></span>:<div>
<div><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks for the response Remi-C. Could you please give me a brief overview of what the workaround would involve? Is this a reported issue?<br>
</div><div class="gmail_extra"><div><div><br><br><div class="gmail_quote">On Fri, May 23, 2014 at 8:08 AM, Rémi Cura <span dir="ltr"><<a href="mailto:remi.cura@gmail.com" target="_blank">remi.cura@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hey,<br>it looks like a classical precision issue.<br></div><div>There are some workaround but they are a little bit annoying.<br>
</div><div><br>Cheers,<br></div>Rémi-C<br></div><div class="gmail_extra">
<br><br><div class="gmail_quote">2014-05-23 13:46 GMT+02:00 Jeff Adams - NOAA Affiliate <span dir="ltr"><<a href="mailto:jeff.adams@noaa.gov" target="_blank">jeff.adams@noaa.gov</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div>
<div dir="ltr">Greetings,<br><br>I have been working with the st_split function and have been receiving strange results. Specifically, I have been using a polygon geometry to split a linestring geometry. After the split I have been using st_within to identify which of the resulting split linestring geometries are inside and which are outside. Sometimes the st_within results are as expected, other times, split linestring geometries that are clearly within the polygon feature (they were created using the polygon as the blade) are not identified as so. When checking in ArcGIS, the features that returned false using the st_within function in PostGIS (but by the nature of how they were created should be within the polygon) are being identified by ArcGIS as being within the polygon. Does anybody know why PostGIS' st_within is returning false with these features? Any workarounds? I am performing this analysis on a fairly large dataset. <br>
<br>Thanks in advance...<span><font color="#888888"><br clear="all"><div dir="ltr">Jeff<br></div><div>
</div></font></span></div>
<br></div></div>_______________________________________________<br>
postgis-users mailing list<br>
<a href="mailto:postgis-users@lists.osgeo.org" target="_blank">postgis-users@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users" target="_blank">http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users</a><br></blockquote></div><br></div>
<br>_______________________________________________<br>
postgis-users mailing list<br>
<a href="mailto:postgis-users@lists.osgeo.org" target="_blank">postgis-users@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users" target="_blank">http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users</a><br></blockquote></div><br><br clear="all"><br></div></div><span><font color="#888888">-- <br>
<div dir="ltr">
Jeffrey D. Adams<br>Contractor<br>OAI, Inc.<br>In support of:<br>National Marine Fisheries Service<br>Office of Protected Resources<br>1315 East West Hwy, Building SSMC3<br>Silver Spring, MD 20910<br>phone: <a href="tel:%28301%29%20427-8434" value="+13014278434" target="_blank">(301) 427-8434</a><br>
fax: <a href="tel:%28301%29%20713-0376" value="+13017130376" target="_blank">(301) 713-0376</a></div>
</font></span></div>
<br>_______________________________________________<br>
postgis-users mailing list<br>
<a href="mailto:postgis-users@lists.osgeo.org" target="_blank">postgis-users@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users" target="_blank">http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users</a><br></blockquote></div></div></div><br></div>
<br>_______________________________________________<br>
postgis-users mailing list<br>
<a href="mailto:postgis-users@lists.osgeo.org" target="_blank">postgis-users@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users" target="_blank">http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users</a><br></blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr">
Jeffrey D. Adams<br>Contractor<br>OAI, Inc.<br>In support of:<br>National Marine Fisheries Service<br>Office of Protected Resources<br>1315 East West Hwy, Building SSMC3<br>Silver Spring, MD 20910<br>phone: (301) 427-8434<br>
fax: (301) 713-0376</div>
</div>
</div></div><br>_______________________________________________<br>
postgis-users mailing list<br>
<a href="mailto:postgis-users@lists.osgeo.org">postgis-users@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users" target="_blank">http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users</a><br></blockquote></div><br></div>