[postgis-devel] Postgis "Split" with tolerance

[Sandro Santilli]

On Fri, Nov 29, 2013 at 09:26:07AM -0800, Paul Ramsey wrote:
> Just to be a loose cannon in general: we have hard-wired tolerances
> all over the code base, just grep for EPSILON and see what pops out.
> We've hardly been ascetics about abusing tolerances where it suits our
> purposes. The proposal for a "split that 'works'" fits in with our
> general historical approach to tolerances that make things "work".

Yeah, and I'll confess: I've injected some of that myself too,
recently. See r10973 ...

What can I say Remi, give me a testcase and let's add to the mud :)

--strk(I wanna be Anarchy);

> 
> P.
> 
> On Fri, Nov 29, 2013 at 5:18 AM, Sandro Santilli <strk at keybit.net> wrote:
> > 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
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel

-- 

 ()  ASCII ribbon campaign        - against html e-mail
 /\  http://www.asciiribbon.org   - against proprietary attachments