[postgis-devel] Postgis "Split" with tolerance

Paul Ramsey pramsey at cleverelephant.ca
Fri Nov 29 09:26:07 PST 2013


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".

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



More information about the postgis-devel mailing list