No problem, 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. Cheers, Rémi-C
2014-05-23 15:58 GMT+02:00 Jeff Adams - NOAA Affiliate <jeff.ad...@noaa.gov> : > 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! > > > On Fri, May 23, 2014 at 9:41 AM, Rémi Cura <remi.c...@gmail.com> wrote: > >> The idea is ST_Within(A,B) is true if no point (mathematical sense) of A >> is outside of B. >> >> 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. >> The problem is, this point could be in either side of the line depending >> of the rounding error of the computing. >> >> It is not "reported" because it is the limit of the current postGis >> approach regarding numerical precision. >> >> The solution either involve enforcing the knowledge you have of what you >> want >> (for instance, force the point that was created by the split to be on the >> boundary of the polygon) >> or use error threshold (effectively becoming fuzzy predicates). >> >> 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. >> Here you could use ST_Max_Distance to filter out outside geometries. >> >> 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. >> ) >> >> >> 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. >> >> Cheers; >> Rémi-C >> >> >> >> >> >> >> 2014-05-23 14:28 GMT+02:00 Jeff Adams - NOAA Affiliate < >> jeff.ad...@noaa.gov>: >> >> 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? >>> >>> >>> On Fri, May 23, 2014 at 8:08 AM, Rémi Cura <remi.c...@gmail.com> wrote: >>> >>>> Hey, >>>> it looks like a classical precision issue. >>>> There are some workaround but they are a little bit annoying. >>>> >>>> Cheers, >>>> Rémi-C >>>> >>>> >>>> 2014-05-23 13:46 GMT+02:00 Jeff Adams - NOAA Affiliate < >>>> jeff.ad...@noaa.gov>: >>>> >>>>> Greetings, >>>>> >>>>> 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. >>>>> >>>>> Thanks in advance... >>>>> Jeff >>>>> >>>>> _______________________________________________ >>>>> postgis-users mailing list >>>>> postgis-users@lists.osgeo.org >>>>> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users >>>>> >>>> >>>> >>>> _______________________________________________ >>>> postgis-users mailing list >>>> postgis-users@lists.osgeo.org >>>> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users >>>> >>> >>> >>> >>> -- >>> Jeffrey D. Adams >>> Contractor >>> OAI, Inc. >>> In support of: >>> National Marine Fisheries Service >>> Office of Protected Resources >>> 1315 East West Hwy, Building SSMC3 >>> Silver Spring, MD 20910 >>> phone: (301) 427-8434 >>> fax: (301) 713-0376 >>> >>> _______________________________________________ >>> postgis-users mailing list >>> postgis-users@lists.osgeo.org >>> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users >>> >> >> >> _______________________________________________ >> postgis-users mailing list >> postgis-users@lists.osgeo.org >> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users >> > > > > -- > Jeffrey D. Adams > Contractor > OAI, Inc. > In support of: > National Marine Fisheries Service > Office of Protected Resources > 1315 East West Hwy, Building SSMC3 > Silver Spring, MD 20910 > phone: (301) 427-8434 > fax: (301) 713-0376 > > _______________________________________________ > postgis-users mailing list > postgis-users@lists.osgeo.org > http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users >
_______________________________________________ postgis-users mailing list postgis-users@lists.osgeo.org http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users