[postgis-users] Spurious Results using ST_Split

[Rémi Cura]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20140523/add38caf/attachment.html>