[postgis-users] st_split

[Rémi Cura]

Hey Sandro,
I disagree,

None of the points returned are "truly" on the line (coordinates should be
fraction, like in CGAL), but close enough to be considered on the line.
It's an hypothesis implictly hard written in all the spatial testing
function because they work up to a certain precision (probably system
dependent).

For the moment it appears that the point we can represent are those on a
grid of size depending of digits used.
In best case it would be on a grid of width 10^-15 in unit of projection.
Thus, in theory, SnapAPointToALine could return a point guaranteed to be
within 10^-15 projection unit of line.

A workaround could be to do snapping with triple (and not double), then
rounding the solution the way it ensures that resulting distance is less
than double precision limit, so being transparent for other spatial
relation function.

This is not a problem of point representation, but a problem of spatial
relation evaluation after.

For the moment, is has not been taken into account, and would be very hard
to do.

We would need either to extend the logic we use (like true, false, maybe,
non true, non false, non maybe), or use CGAL like approach.

Both are difficult and so for the moment we have to keep on with what we
have B-) , or use SFCGAL !

Cheers,

Rémi-C



2013/10/29 Sandro Santilli <strk at keybit.net>

> On Tue, Oct 29, 2013 at 12:52:28PM +0100, Rémi Cura wrote:
> > The problem is there is no function ST_Snap( a point to a line), only
> > ST_Snap (a line to a point) !
> >
> > I don't know why because snapping a line to a point is way more
> difficult.!
>
> Snapping a point to a line can be _impossible_.
> Not all points on a line can be represented using finite numbers,
> while if a point exists you can surely snap to it...
>
> --strk;
> _______________________________________________
> 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/20131029/1b798aa2/attachment.html>