[postgis-devel] Postgis "Split" with tolerance

[Rémi Cura]

Hmm still I understand that you may want to have one and only parameter,
and not a tolerance parameter build upon a precision parameter
If it was to be used set, what would you suggest as a mechanism?
Cheers,

Rémi-C


2013/11/29 Rémi Cura <remi.cura at gmail.com>

> 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/ddd919f0/attachment.html>