[postgis-devel] Postgis "Split" with tolerance

[Rémi Cura]

Hey Sandro ,
thanks for taking the time to answer =)

I feel we are talking about 2 different things :
you want a global tolerance policy for Postgis, so do I, *but this is not
the purpose of this proposed change. (it would be very difficult anyway)*
Here we just try to fix a broken numerical computation to cop with a double
computing errors.

1. about tolerance :

with the precision change, the line won't move, it will "seem" wider to the
ST_Split function, that's all (and it already has an implicit "width"
anyway )

In perticular, the beginning and end of the segment won't change. (no
translation! )

2. about workaround dirty trick :

I totally disagree. To cop with the split(line,line) precision issue, one
would have to create a "big" cutting line out of the point, useless and not
safe ( up to 9 digits??).

3. about this broken split function :

I don't see the point of keeping as is a function which has been proven to
be broken. Either we fix it or we replace it ?

4. about example of precision :

I give this example to give a feel of what 12 digits precision is.
Everybody doesn't use meter, but everybody uses geographical information
from real world. This examples are just examples to show that having such a
precision is already precise enough for real world data (else, use CGAL,
because there is no way to get better result with double computation).
Also, the proposed change doesn't make the precision to 10^-12, but instead
to 12 digits (thus totally independent of unity used).

5. about a precision parameter :

(Sadly people don't seem much interested by this problem.)


For me the user could have a *tolerance* parameter , this is not what we
are talking about.

Here this precision parameter would be much more low level, and not exposed
to the user !
The big difference is that when changing the precision of computing, it
could create errors in further computing (example : in the beginning of
split function, the point is supposed to be on the line, but then when the
geos function tries to cut the line, the point is not on the line for geos,
and it crashes).

It should be a constant, like the number of bits in an int or whatever.

What would you think of setting it at compilation time?
(something like "NUMERICFLAGS" )

Cheers,
Rémi-C







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

> On Fri, Nov 29, 2013 at 10:48:54AM +0100, Rémi Cura wrote:
> > ST_Split(line,point) is currently broken.
> > This is quite a neutral statement, because given a random point on a
> random
> > line, split won't do anything (p_correct_answer<1/10k )!
> >
> > The only work around I can think about are
> > _ snap the line to the point : it implies moving the line, which is not
> an
> > option if you do it several times with different points, and is more
> > abstractly a very bad idea
>
> This is what you'd be doing anyway by implementing a tolerance.
> That is, the line would be moved anyway.
>
> > _ change the point to a very small line in the perpendicular direction of
> > the line we want to split, then use split(line,line). Again not a very
> good
> > option because you would possibiliy split the line in more than one point
> > (and anyway split(line,line) has also precision issues).
>
> Still this is a legit options.
>
> > I understand PostGIS is a big project and we have to be conservative,
> > that is "we don't break a fine function with changes bringing unknown
> > consequences for unproven benefits",
> > but this function is broken, and we could change it to a function working
> > most of the time   !
>
> Yes, we could change it by accepting a tolerance value.
> What's wrong with that ?
>
> > *Pros of this change :*
> >
> > _a line will be split by a point correctly (p_error < 10^6)
> > _no heavy changes in code or methods
> >
> > *Cons of this change :*
> >
> > _the line would be split by any points close enough (lengthofline/10^12).
> > (that is all points less than 10 micro meters away from a line 1000 km
> long
> > !).
>
> PostGIS doesn't deal with unit, so you don't know if those are
> micro meters or micro peta meters.
> You might be splitting a milli meter line by a point...
>
> All I'm saying is I'd like precision/tolerance to be _EXPLICIT_.
> Particularely important when you're about to run a _set_ of operations
> and you want them to be _consistent_ as per precision.
>
> > *I would also like adding ST_Split(geom,geom,tolerance).*
> > In fact it could be an easy wrapper around ST_Split(geom,geom) if this
> > function was working. (something like: if the point is DWithin, split the
> > closest part of the line)
>
> Please go ahead. Such a function would be accepted.
>
> NOTE: TopoGeo_addPoint does take a tolerane, and does use ST_Split after
>       snapping the line to a DWithin point to implement it.
>       Haing it available natively in C would speed that up.
>
> --strk;
>
>  ()  ASCII ribbon campaign        - against html e-mail
>  /\  http://www.asciiribbon.org   - against proprietary attachments
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20131129/976153bc/attachment.html>