[postgis-users] Spurious Results using ST_Split

[Rémi Cura]

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.adams at 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.cura at 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.adams at 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.cura at 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.adams at 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 at lists.osgeo.org
>>>>> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> postgis-users mailing list
>>>> postgis-users at 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 at lists.osgeo.org
>>> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
>>>
>>
>>
>> _______________________________________________
>> postgis-users mailing list
>> postgis-users at 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 at lists.osgeo.org
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20140523/f4a00256/attachment.html>